[PATCH v3 2/2] 82xx, mgcoge: update defconfig for 2.6.32

2009-08-07 Thread Heiko Schocher
- add I2C support
- add FCC1 and FCC2 support

Signed-off-by: Heiko Schocher h...@denx.de
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
  next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0001-82xx-mgcoge-update-defconfig-for-2.6.32.patch
total: 0 errors, 0 warnings, 134 lines checked

0001-82xx-mgcoge-update-defconfig-for-2.6.32.patch has no obvious style 
problems and is ready for submission.
$

- changes since v1
  - Add comments from David Gibson
removed 2 device_type entries
  - Add comment from Kumar Gala
splittet into 2 patches (seperated defconfig patch)
- changes since v2
  - based against kumars tree, next branch

 arch/powerpc/configs/mgcoge_defconfig |   86 ++--
 1 files changed, 80 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/configs/mgcoge_defconfig 
b/arch/powerpc/configs/mgcoge_defconfig
index e9491c1..30b68bf 100644
--- a/arch/powerpc/configs/mgcoge_defconfig
+++ b/arch/powerpc/configs/mgcoge_defconfig
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.31-rc4
-# Wed Jul 29 23:31:51 2009
+# Linux kernel version: 2.6.31-rc5
+# Fri Aug  7 08:19:15 2009
 #
 # CONFIG_PPC64 is not set

@@ -158,6 +158,7 @@ CONFIG_BASE_SMALL=0
 # CONFIG_MODULES is not set
 CONFIG_BLOCK=y
 CONFIG_LBDAF=y
+CONFIG_BLK_DEV_BSG=y
 # CONFIG_BLK_DEV_INTEGRITY is not set

 #
@@ -506,6 +507,7 @@ CONFIG_MTD_PHYSMAP_OF=y
 # CONFIG_MTD_UBI is not set
 CONFIG_OF_DEVICE=y
 CONFIG_OF_GPIO=y
+CONFIG_OF_I2C=y
 CONFIG_OF_MDIO=y
 # CONFIG_PARPORT is not set
 CONFIG_BLK_DEV=y
@@ -582,7 +584,8 @@ CONFIG_PHYLIB=y
 # CONFIG_STE10XP is not set
 # CONFIG_LSI_ET1011C_PHY is not set
 CONFIG_FIXED_PHY=y
-# CONFIG_MDIO_BITBANG is not set
+CONFIG_MDIO_BITBANG=y
+# CONFIG_MDIO_GPIO is not set
 CONFIG_NET_ETHERNET=y
 CONFIG_MII=y
 # CONFIG_MACE is not set
@@ -608,8 +611,8 @@ CONFIG_MII=y
 # CONFIG_ATL2 is not set
 CONFIG_FS_ENET=y
 CONFIG_FS_ENET_HAS_SCC=y
-# CONFIG_FS_ENET_HAS_FCC is not set
-# CONFIG_FS_ENET_MDIO_FCC is not set
+CONFIG_FS_ENET_HAS_FCC=y
+CONFIG_FS_ENET_MDIO_FCC=y
 # CONFIG_NETDEV_1000 is not set
 # CONFIG_NETDEV_1 is not set
 # CONFIG_TR is not set
@@ -680,7 +683,68 @@ CONFIG_HW_RANDOM=y
 # CONFIG_APPLICOM is not set
 # CONFIG_RAW_DRIVER is not set
 CONFIG_DEVPORT=y
-# CONFIG_I2C is not set
+CONFIG_I2C=y
+CONFIG_I2C_BOARDINFO=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_HELPER_AUTO=y
+
+#
+# I2C Hardware Bus support
+#
+
+#
+# PC SMBus host controller drivers
+#
+# CONFIG_I2C_ALI1535 is not set
+# CONFIG_I2C_ALI15X3 is not set
+# CONFIG_I2C_AMD756 is not set
+# CONFIG_I2C_AMD8111 is not set
+# CONFIG_I2C_I801 is not set
+# CONFIG_I2C_ISCH is not set
+# CONFIG_I2C_PIIX4 is not set
+# CONFIG_I2C_NFORCE2 is not set
+# CONFIG_I2C_SIS5595 is not set
+# CONFIG_I2C_SIS630 is not set
+# CONFIG_I2C_SIS96X is not set
+# CONFIG_I2C_VIAPRO is not set
+
+#
+# Mac SMBus host controller drivers
+#
+# CONFIG_I2C_POWERMAC is not set
+
+#
+# I2C system bus drivers (mostly embedded / system-on-chip)
+#
+CONFIG_I2C_CPM=y
+# CONFIG_I2C_DESIGNWARE is not set
+# CONFIG_I2C_GPIO is not set
+# CONFIG_I2C_MPC is not set
+# CONFIG_I2C_SIMTEC is not set
+
+#
+# External I2C/SMBus adapter drivers
+#
+# CONFIG_I2C_PARPORT_LIGHT is not set
+
+#
+# Graphics adapter I2C/DDC channel drivers
+#
+# CONFIG_I2C_VOODOO3 is not set
+
+#
+# Other I2C/SMBus bus drivers
+#
+# CONFIG_I2C_PCA_PLATFORM is not set
+
+#
+# Miscellaneous I2C Chip support
+#
+# CONFIG_PCF8575 is not set
+# CONFIG_I2C_DEBUG_CORE is not set
+# CONFIG_I2C_DEBUG_ALGO is not set
+# CONFIG_I2C_DEBUG_BUS is not set
+# CONFIG_I2C_DEBUG_CHIP is not set
 # CONFIG_SPI is not set

 #
@@ -699,6 +763,9 @@ CONFIG_GPIOLIB=y
 #
 # I2C GPIO expanders:
 #
+# CONFIG_GPIO_MAX732X is not set
+# CONFIG_GPIO_PCA953X is not set
+# CONFIG_GPIO_PCF857X is not set

 #
 # PCI GPIO expanders:
@@ -727,7 +794,14 @@ CONFIG_SSB_POSSIBLE=y
 # CONFIG_MFD_CORE is not set
 # CONFIG_MFD_SM501 is not set
 # CONFIG_HTC_PASIC3 is not set
+# CONFIG_TPS65010 is not set
+# CONFIG_TWL4030_CORE is not set
 # CONFIG_MFD_TMIO is not set
+# CONFIG_PMIC_DA903X is not set
+# CONFIG_MFD_WM8400 is not set
+# CONFIG_MFD_WM8350_I2C is not set
+# CONFIG_MFD_PCF50633 is not set
+# CONFIG_AB3100_CORE is not set
 # CONFIG_REGULATOR is not set
 # CONFIG_MEDIA_SUPPORT is not set

-- 
1.6.0.6

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/3] arch/powerpc: Add kmalloc NULL tests

2009-08-07 Thread Julia Lawall
On Fri, 7 Aug 2009, Daniel K. wrote:

 Julia Lawall wrote:
  --- a/arch/powerpc/sysdev/fsl_rio.c
  +++ b/arch/powerpc/sysdev/fsl_rio.c
  @@ -1057,6 +1057,10 @@ int fsl_rio_setup(struct of_device *dev)
  law_start, law_size);
   
  ops = kmalloc(sizeof(struct rio_ops), GFP_KERNEL);
  +   if (!ops) {
  +   rc = -ENOMEM;
  +   goto err_ops;
  +   }
ops-lcread = fsl_local_config_read;
ops-lcwrite = fsl_local_config_write;
ops-cread = fsl_rio_config_read;
  @@ -1064,6 +1068,10 @@ int fsl_rio_setup(struct of_device *dev)
ops-dsend = fsl_rio_doorbell_send;
   
  port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL);
  +   if (!port) {
  +   rc = -ENOMEM;
  +   goto err_port;
  +   }
port-id = 0;
port-index = 0;
   
  @@ -1071,7 +1079,7 @@ int fsl_rio_setup(struct of_device *dev)
if (!priv) {
 printk(KERN_ERR Can't alloc memory for 'priv'\n);
 rc = -ENOMEM;
  -   goto err;
  +   goto err_priv;
}
   
INIT_LIST_HEAD(port-dbells);
  @@ -1169,13 +1177,15 @@ int fsl_rio_setup(struct of_device *dev)
   
  return 0;
  err:
  -   if (priv)
  -   iounmap(priv-regs_win);
  -   kfree(ops);
  +   iounmap(priv-regs_win);
  +err_priv:
  kfree(priv);
  +err_port:
  kfree(port);
  +err_ops:
  +   kfree(ops);
return rc;
 
 There seems to be a goto-off-by-one error here.
 
 If  = kxalloc() fails, you goto err_, and do a kfree() where 
 is
 already proven to be NULL.
 
 Is there a reason for this that eludes me?

No, I messed up...  I will fix it.

julia


 I'd expect that last hunk to look something like
 
 @@ -1169,13 +1177,15 @@ int fsl_rio_setup(struct of_device *dev)
 
   return 0;
 err:
 - if (priv)
 - iounmap(priv-regs_win);
 - kfree(ops);
 + iounmap(priv-regs_win);
   kfree(priv);
 +err_priv:
   kfree(port);
 +err_port:
 + kfree(ops);
 +err_ops:
   return rc;
 }
 
 
 Daniel K.
 --
 To unsubscribe from this list: send the line unsubscribe kernel-janitors in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 1/3] arch/powerpc: Add kmalloc NULL tests

2009-08-07 Thread Daniel K.

Julia Lawall wrote:

--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1057,6 +1057,10 @@ int fsl_rio_setup(struct of_device *dev)
law_start, law_size);
 
 	ops = kmalloc(sizeof(struct rio_ops), GFP_KERNEL);

+   if (!ops) {
+   rc = -ENOMEM;
+   goto err_ops;
+   }
ops-lcread = fsl_local_config_read;
ops-lcwrite = fsl_local_config_write;
ops-cread = fsl_rio_config_read;
@@ -1064,6 +1068,10 @@ int fsl_rio_setup(struct of_device *dev)
ops-dsend = fsl_rio_doorbell_send;
 
 	port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL);

+   if (!port) {
+   rc = -ENOMEM;
+   goto err_port;
+   }
port-id = 0;
port-index = 0;
 
@@ -1071,7 +1079,7 @@ int fsl_rio_setup(struct of_device *dev)

if (!priv) {
printk(KERN_ERR Can't alloc memory for 'priv'\n);
rc = -ENOMEM;
-   goto err;
+   goto err_priv;
}
 
 	INIT_LIST_HEAD(port-dbells);

@@ -1169,13 +1177,15 @@ int fsl_rio_setup(struct of_device *dev)
 
 	return 0;

 err:
-   if (priv)
-   iounmap(priv-regs_win);
-   kfree(ops);
+   iounmap(priv-regs_win);
+err_priv:
kfree(priv);
+err_port:
kfree(port);
+err_ops:
+   kfree(ops);
return rc;


There seems to be a goto-off-by-one error here.

If  = kxalloc() fails, you goto err_, and do a kfree() where  is
already proven to be NULL.

Is there a reason for this that eludes me?


I'd expect that last hunk to look something like

@@ -1169,13 +1177,15 @@ int fsl_rio_setup(struct of_device *dev)

return 0;
err:
-   if (priv)
-   iounmap(priv-regs_win);
-   kfree(ops);
+   iounmap(priv-regs_win);
kfree(priv);
+err_priv:
kfree(port);
+err_port:
+   kfree(ops);
+err_ops:
return rc;
}


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


Re: [PATCH 1/3] arch/powerpc: Add kmalloc NULL tests

2009-08-07 Thread Julia Lawall
From: Julia Lawall ju...@diku.dk

Check that the result of kmalloc/kzalloc is not NULL before dereferencing it.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// smpl
@@
expression *x;
identifier f;
constant char *C;
@@

x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x == NULL
when != x != NULL
when != (x || ...)
(
kfree(x)
|
f(...,C,...,x,...)
|
*f(...,x,...)
|
*x-f
)
// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk

---
 arch/powerpc/sysdev/fsl_rio.c   |   18 ++
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index cbb3bed..757a83f 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1057,6 +1057,10 @@ int fsl_rio_setup(struct of_device *dev)
law_start, law_size);
 
ops = kmalloc(sizeof(struct rio_ops), GFP_KERNEL);
+   if (!ops) {
+   rc = -ENOMEM;
+   goto err_ops;
+   }
ops-lcread = fsl_local_config_read;
ops-lcwrite = fsl_local_config_write;
ops-cread = fsl_rio_config_read;
@@ -1064,6 +1068,10 @@ int fsl_rio_setup(struct of_device *dev)
ops-dsend = fsl_rio_doorbell_send;
 
port = kzalloc(sizeof(struct rio_mport), GFP_KERNEL);
+   if (!port) {
+   rc = -ENOMEM;
+   goto err_port;
+   }
port-id = 0;
port-index = 0;
 
@@ -1071,7 +1079,7 @@ int fsl_rio_setup(struct of_device *dev)
if (!priv) {
printk(KERN_ERR Can't alloc memory for 'priv'\n);
rc = -ENOMEM;
-   goto err;
+   goto err_priv;
}
 
INIT_LIST_HEAD(port-dbells);
@@ -1169,11 +1177,13 @@ int fsl_rio_setup(struct of_device *dev)
 
return 0;
 err:
-   if (priv)
-   iounmap(priv-regs_win);
-   kfree(ops);
+   iounmap(priv-regs_win);
kfree(priv);
+err_priv:
kfree(port);
+err_port:
+   kfree(ops);
+err_ops:
return rc;
 }
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: MPC8313 performance evaluation

2009-08-07 Thread Lutz Jaenicke
On Thu, Aug 06, 2009 at 02:16:55PM -0500, Kumar Gala wrote:

 On Aug 6, 2009, at 1:00 PM, Lutz Jaenicke wrote:
 With the mpc8...@400mhz I get a throughput of approx. 24500 frames/s
 using the predefined firewall rules.

 With the MPC8313 I get a significantly lower value:
 mpc8...@250mhz  12500fps
 mpc8...@333mhz  14500fps
 mpc8...@416mhz  15500fps  (333MHz type, overclocked)

 What DDR frequencies (and width) are you running the 8343 vs 8313 at.   
 This can have a significant impact on performance.

The 8343 is running DDR2 32bit at 266MHz (CSB 266MHz)
The 8313 is running DDR2 32bit at 333MHz (CSB 166MHz)

The test were performed with 128byte frames so that the overall
bandwidth needed is far below even 100Mbit/s.

Best regards,
Lutz
-- 
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG  /protecting industrial networks/
tel: +49.30.921028-200
fax: +49.30.921028-020
Rudower Chaussee 13
D-12489 Berlin, Germany
www.innominate.com

Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Volker Bibelhausen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: MPC8313 performance evaluation

2009-08-07 Thread Liu Dave-R63238
  On Aug 6, 2009, at 1:00 PM, Lutz Jaenicke wrote:
  With the mpc8...@400mhz I get a throughput of approx. 
 24500 frames/s
  using the predefined firewall rules.
 
  With the MPC8313 I get a significantly lower value:
  mpc8...@250mhz  12500fps
  mpc8...@333mhz  14500fps
  mpc8...@416mhz  15500fps  (333MHz type, overclocked)
 
  What DDR frequencies (and width) are you running the 8343 
 vs 8313 at.   
  This can have a significant impact on performance.
 
 The 8343 is running DDR2 32bit at 266MHz (CSB 266MHz)
 The 8313 is running DDR2 32bit at 333MHz (CSB 166MHz)
 
 The test were performed with 128byte frames so that the overall
 bandwidth needed is far below even 100Mbit/s.

The CSB bus freq is key for the throught.
CSB freq of 8313 is lower than 8343, it will cause the performance
degrade.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH][v2][powerpc/85xx] P2020RDB Platform Support Added

2009-08-07 Thread Poonam Aggrwal
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
  DDR2 1G
- NOR Flash
  16MByte
- NAND Flash
  32MByte
- 3 Ethernet interfaces
  1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
  2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
  3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM

Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
incorporated Felix feedback regarding the partition names.
fixed the vitesse switch ranges entry in device tree.
 arch/powerpc/boot/dts/p2020rdb.dts|  586 +
 arch/powerpc/configs/mpc85xx_defconfig|1 +
 arch/powerpc/platforms/85xx/Kconfig   |9 +
 arch/powerpc/platforms/85xx/Makefile  |3 +-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  141 +++
 5 files changed, 739 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p2020rdb.dts
 create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c

diff --git a/arch/powerpc/boot/dts/p2020rdb.dts 
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..617029f
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+   model = fsl,P2020;
+   compatible = fsl,P2020RDB;
+   #address-cells = 2;
+   #size-cells = 2;
+
+   aliases {
+   ethernet0 = enet0;
+   ethernet1 = enet1;
+   ethernet2 = enet2;
+   serial0 = serial0;
+   serial1 = serial1;
+   pci0 = pci0;
+   pci1 = pci1;
+   };
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   PowerPC,p2...@0 {
+   device_type = cpu;
+   reg = 0x0;
+   next-level-cache = L2;
+   };
+
+   PowerPC,p2...@1 {
+   device_type = cpu;
+   reg = 0x1;
+   next-level-cache = L2;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   };
+
+   local...@ffe05000 {
+   #address-cells = 2;
+   #size-cells = 1;
+   compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+   reg = 0 0xffe05000 0 0x1000;
+   interrupts = 19 2;
+   interrupt-parent = mpic;
+
+   /* NOR and NAND Flashes */
+   ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0002;
+
+   n...@0,0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = cfi-flash;
+   reg = 0x0 0x0 0x100;
+   bank-width = 2;
+   device-width = 1;
+
+   partit...@0 {
+   /* This location must not be altered  */
+   /* 256KB for Vitesse 7385 Switch firmware */
+   reg = 0x0 0x0004;
+   label = NOR (RO) Vitesse-7385 Firmware;
+   read-only;
+   };
+
+   partit...@4 {
+   /* 256KB for DTB Image */
+   reg = 0x0004 0x0004;
+   label = NOR (RO) DTB Image;
+   read-only;
+   };
+
+   partit...@8 {
+   /* 3.5 MB for Linux Kernel Image */
+   reg = 0x0008 0x0038;
+   label = NOR (RO) Linux Kernel Image;
+   read-only;
+   };
+
+   partit...@40 {
+   /* 11MB for JFFS2 based Root file System */
+   reg = 0x0040 0x00b0;
+   label = NOR (RW) JFFS2 Root File System;
+ 

Question about powerpc branch instructions

2009-08-07 Thread HongWoo Lee

Hi~

I want to know about bl instruction and the difference between branch 
instructions.

I found this code segment.

{{{

bl  go_to_real
insrdi  r18, r19, 32, 0

}}}

And I found the explanation about branch instructions in PowerISA 2.06 
document.


{{{
b target_addr (AA=0 LK=0)
ba target_addr (AA=1 LK=0)
bl target_addr (AA=0 LK=1)
bla target_addr (AA=1 LK=1)

If AA=0 then the branch target address is the sum of LI || 0b00 
sign-extended and the address of this instruction,
with the high-order 32 bits of the branch target address set to 0 in 
32-bit mode.


If AA=1 then the branch target address is the value LI || 0b00 
sign-extended,
with the high-order 32 bits of the branch target address set to 0 in 
32-bit mode.


If LK=1 then the effective address of the instruction following the 
Branch instruction is placed into the Link Register.

}}}

Questions
#1: Is there any special reason to concatenate 0b00 ?  Why 0b00 ??
#2: Is b similar to the jmp in x86 ? and bl is similar to the call in x86 ?

Thanks in advance.

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


Re: Question about powerpc branch instructions

2009-08-07 Thread Benjamin Herrenschmidt
On Fri, 2009-08-07 at 17:47 +0900, HongWoo Lee wrote:

 #1: Is there any special reason to concatenate 0b00 ?  Why 0b00 ??

Because instructions have to be aligned on 4 bytes boundaries ?

 #2: Is b similar to the jmp in x86 ? and bl is similar to the call in x86 ?

I'm not totally familiar with x86 but I sounds like it, though of
course they can be (ab)used in some more subtle ways.

Cheers,
Ben.

 Thanks in advance.
 
 HongWoo.
 ___
 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: MPC8313 performance evaluation

2009-08-07 Thread Lutz Jaenicke
On Fri, Aug 07, 2009 at 04:08:50PM +0800, Liu Dave-R63238 wrote:
 
  Some discussion with the the freescale rep. lead to the CSB frequency
  of the 8313 (166MHz) being significantly lower than that of the 8343.
  Is the CSB the critical point here?
 
 I believe the CSB is critical point here. They are right.

I have performed some additional measurements with other multiplier/divider
settings 

Previous values with CSB=166MHz
  With the MPC8313 I get a significantly lower value:
  mpc8...@250mhz  12500fps
  mpc8...@333mhz  14500fps
  mpc8...@416mhz  15500fps  (333MHz type, overclocked)

New value with CSB=200MHz (overclocked)
 mpc8...@400mhz  17500fps

This indeed indicates that the CSB is the limiting factor.
Until a few days ago I have not even been aware of the CSB being a
performance critical component. All of the nice powerpoints explaining
the processors and used for comparing different families shown by the
Freescale Rep include the core frequencies and the DRAM interface
and frequency but do not even mention the CSB...

  Note: the IXP42x uses an internal bus speed of 133MHz and operates
  at frame rates similar to the 8343...
 
 It is possible, IXP42x has the differenet SoC architecture with 83xx.

That is very true indeed, then XScale (ARM) based IXP42x does have
a completely different implementation.

Best regards,
Lutz
-- 
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG  /protecting industrial networks/
tel: +49.30.921028-200
fax: +49.30.921028-020
Rudower Chaussee 13
D-12489 Berlin, Germany
www.innominate.com

Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Volker Bibelhausen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: MPC8313 performance evaluation

2009-08-07 Thread Lutz Jaenicke
On Fri, Aug 07, 2009 at 12:56:54PM +0200, Lutz Jaenicke wrote:
 On Fri, Aug 07, 2009 at 04:08:50PM +0800, Liu Dave-R63238 wrote:
  
   Some discussion with the the freescale rep. lead to the CSB frequency
   of the 8313 (166MHz) being significantly lower than that of the 8343.
   Is the CSB the critical point here?
  
  I believe the CSB is critical point here. They are right.
 
 This indeed indicates that the CSB is the limiting factor.
 Until a few days ago I have not even been aware of the CSB being a
 performance critical component. All of the nice powerpoints explaining
 the processors and used for comparing different families shown by the
 Freescale Rep include the core frequencies and the DRAM interface
 and frequency but do not even mention the CSB...

Having this said, is there any good white paper to be read about it?
For firewall usage there are different influence factors:
* Ethernet interfaces (DMA to/from DRAM via CSB!?)
* CPU processing for the firewall rules (code/data to/from DRAM closely
  related to cache size or misses)
Hence I would like to understand better the impact of the different
components.
(If only available under NDA I can also contact my Freescale Rep but
having public source always makes things easier.)

Best regards,
Lutz
-- 
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG  /protecting industrial networks/
tel: +49.30.921028-200
fax: +49.30.921028-020
Rudower Chaussee 13
D-12489 Berlin, Germany
www.innominate.com

Register Court: AG Charlottenburg, HR B 81603
Management Board: Dirk Seewald
Chairman of the Supervisory Board: Volker Bibelhausen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Linux booting problem

2009-08-07 Thread Sumesh Kaana

Hi all,
I am trying to boot linux kernel (2.6.30) on a custom built board.I am using 
simple ppc platform and attached are my dts file and boot log..
I've 26Mb of RAM,UART and UIC with powerpc 440x5 processor.Kernel Image size is 
less than 1 mb.
cgc,skybeam  board is added in arch/powerpc/platforms/44x/ppc44x_simple.c
device tree file as bellow:
/dts-v1/;
/ { model = cgc,skybeam;  compatible = cgc,skybeam; #address-cells 
= 1;   #size-cells = 1;  dcr-parent = SKYBEAM_PPC;chosen 
 {   bootargs = console=ttyS0 root=/dev/ram;   
linux,stdout-path = /plb/ser...@0208; } ; aliases {   
serial0 = STD_UART;} ; memory  {   
device_type = memory; reg =  0x0 0x01A0 ;   } ; 
cpus {  #address-cells = 1;   #size-cells = 0;  
SKYBEAM_PPC: c...@0 {   device_type = cpu;
#address-cells = 1;   #size-cells = 1;  
reg = 0;  clock-frequency = 2500;   
compatible = PowerPC,440, ibm,ppc440;   
d-cache-line-size = 0x20; d-cache-size = 0x8000;
dcr-access-method = native;   dcr-controller 
;i-cache-line-size = 0x20; 
i-cache-size = 0x8000;model = PowerPC,440;  
timebase-frequency = 2500;} ; } ; 
UIC0: interrupt-controller0 {   compatible = ibm,uic-440ep,ibm,uic; 
interrupt-controller;   cell-index = 0;   dcr-reg 
= 0x1c0 0x009;#address-cells = 0;   #size-cells = 
0;  #interrupt-cells = 2; };  PLB: plb {
  #address-cells = 1;   #size-cells = 1;  compatible = 
simple-bus;  ranges ;STD_UART: 
ser...@0208 { device_type = serial; 
compatible = ns16550; reg = 0x0208 0x0008;  
virtual-reg = 0x0208;clock-frequency = 12500;   
current-speed = 9600; interrupt-parent = 
UIC0; interrupts = 0x5 0x4; } ; } ;}  ;
boot log is as below:-

zImage starting: loaded at 0x0040 (sp: 0x004deeb0)Allocating 0x1dad84 bytes 
for kernel ...gunzipping (0x - 0x0040c000:0x004dd3fc)...done 0x1c31cc 
bytes
Linux/PowerPC load: console=ttyS0 root=/dev/ramFinalizing device tree... flat 
tree at 0x4eb300Debug print:This worksDebug 
print:###Memory hole size: 0MB
Unable to handle kernel paging request for data at address 0x01a0Faulting 
instruction address: 0xc0011434Oops: Kernel access of bad area, sig: 11 
[#1]PREEMPT PowerPC 44x PlatformModules linked in:NIP: c0011434 LR: c010dcb0 
CTR: 0001REGS: c01bfe60 TRAP: 0300   Not tainted  (2.6.30)MSR: 00021000 
ME,CE  CR: 2224  XER: 2000DEAR: 01a0, ESR: TASK = 
c01a94b8[0] 'swapper' THREAD: c01be000GPR00: fff4 c01bff10 c01a94b8 
01a0 019f 000c c01958b0 GPR08: 0037 c011 0042 
3fff 2222  f104 GPR16:    
   c010d750 c01958b0GPR24: 000c  c01a1dfc 
01a0 c01a1dfc 3fff 000c NIP [c0011434] strlen+0x4/0x18LR 
[c010dcb0] match_token+0x1a0/0x228Call Trace:[c01bff50] [c01962f4] 
free_area_init_nodes+0x48/0x3a0[c01bff80] [c0191738] 
paging_init+0x80/0xa0[c01bffb0] [c01909b4] setup_arch+0x1c4/0x1dc[c01bffc0] 
[c018c648] start_kernel+0x54/0x288[c01bfff0] [c200] 
skpinv+0x190/0x1ccInstruction dump:4d820020 7ca903a6 38a3 3884 8c650001 
2c83 8c040001 7c6018514d860020 4102ffec 4e800020 3883 8c040001 
2c00 4082fff8 7c632050---[ end trace 31fd0ba7d8756001 ]---Kernel panic - 
not syncing: Attempted to kill the idle task!Call Trace:[c01bfd40] [c0005d5c] 
show_stack+0x4c/0x16c (unreliable)[c01bfd80] [c002f174] 
panic+0xa0/0x168[c01bfdd0] [c0032eb0] do_exit+0x61c/0x638[c01bfe10] [c000b60c] 
kernel_bad_stack+0x0/0x4c[c01bfe40] [c000f328] 
bad_page_fault+0x90/0xd8[c01bfe50] [c000e19c] 
handle_page_fault+0x7c/0x80[c01bff10] [] (null)[c01bff50] [c01962f4] 
free_area_init_nodes+0x48/0x3a0[c01bff80] [c0191738] 
paging_init+0x80/0xa0[c01bffb0] [c01909b4] setup_arch+0x1c4/0x1dc[c01bffc0] 
[c018c648] start_kernel+0x54/0x288[c01bfff0] [c200] 
skpinv+0x190/0x1ccRebooting in 180 seconds..


Can anyone tell what would be the problem..?


thanks,Sumesh.


Check the daily blob for the latest on what's happening around the web What 
goes online, stays online
_
Need a new model in your life? Sell your car fast.

Re: [PATCH][v2][powerpc/85xx] P2020RDB Platform Support Added

2009-08-07 Thread Felix Radensky

Hi, Poonam

See some more comments below.

Poonam Aggrwal wrote:

Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
  DDR2 1G
- NOR Flash
  16MByte
- NAND Flash
  32MByte
- 3 Ethernet interfaces
  1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
  2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
  3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM

Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
incorporated Felix feedback regarding the partition names.
fixed the vitesse switch ranges entry in device tree.
 arch/powerpc/boot/dts/p2020rdb.dts|  586 +
 arch/powerpc/configs/mpc85xx_defconfig|1 +
 arch/powerpc/platforms/85xx/Kconfig   |9 +
 arch/powerpc/platforms/85xx/Makefile  |3 +-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  141 +++
 5 files changed, 739 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p2020rdb.dts
 create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c

diff --git a/arch/powerpc/boot/dts/p2020rdb.dts 
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..617029f
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+   model = fsl,P2020;
+   compatible = fsl,P2020RDB;
+   #address-cells = 2;
+   #size-cells = 2;
+
+   aliases {
+   ethernet0 = enet0;
+   ethernet1 = enet1;
+   ethernet2 = enet2;
+   serial0 = serial0;
+   serial1 = serial1;
+   pci0 = pci0;
+   pci1 = pci1;
+   };
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   PowerPC,p2...@0 {
+   device_type = cpu;
+   reg = 0x0;
+   next-level-cache = L2;
+   };
+
+   PowerPC,p2...@1 {
+   device_type = cpu;
+   reg = 0x1;
+   next-level-cache = L2;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   };
+
+   local...@ffe05000 {
+   #address-cells = 2;
+   #size-cells = 1;
+   compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+   reg = 0 0xffe05000 0 0x1000;
+   interrupts = 19 2;
+   interrupt-parent = mpic;
+
+   /* NOR and NAND Flashes */
+   ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0002;
+
+   n...@0,0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = cfi-flash;
+   reg = 0x0 0x0 0x100;
+   bank-width = 2;
+   device-width = 1;
+
+   partit...@0 {
+   /* This location must not be altered  */
+   /* 256KB for Vitesse 7385 Switch firmware */
+   reg = 0x0 0x0004;
+   label = NOR (RO) Vitesse-7385 Firmware;
+   read-only;
+   };
+
+   partit...@4 {
+   /* 256KB for DTB Image */
+   reg = 0x0004 0x0004;
+   label = NOR (RO) DTB Image;
+   read-only;
+   };
+
+   partit...@8 {
+   /* 3.5 MB for Linux Kernel Image */
+   reg = 0x0008 0x0038;
+   label = NOR (RO) Linux Kernel Image;
+   read-only;
+   };
+
+   partit...@40 {
+   /* 11MB for JFFS2 based Root file System */
+   reg = 0x0040 0x00b0;
+   

5121 cache handling.

2009-08-07 Thread Kenneth Johansson
on 5121 there is a e300 core that unfortunately is connected to the rest
of the SOC with a bus that do not support coherency.

solution for many driver has been to use uncached memory. But for the
framebuffer that is not going to work as the performance impact of doing
graphics operations on uncached memory is to large.

currently the solution is to flush the cache in the interrupt
handler. 

#if defined(CONFIG_NOT_COHERENT_CACHE)
int i;
unsigned int *ptr;
ptr  = coherence_data;
for (i = 0; i  1024*8; i++)
*ptr++ = 0;
#endif

Now this apparently is not enough on a e300 core that has a PLRU cache
replacement algorithm. but what is the optimal solution? 

should not the framebuffer be marked as cache write through. that is the
W bit should be set in the tlb mapping. Why is this not done ? is that
feature also not working on 5121 ??

if this manual handling needs to be done what is best. 

do it like now but over 52KB memory basically throwing out anything in
the cache in the process regardless if it was needed or not.

or do it carefully over just the framebuffer memory.

problem with doing it over just the framebuffer is that a 1024x768
buffer is 98304 cache lines it's going to take a considerable time to
do. how many cycles does it take per cache line if we never get a hit ??
3cycles at 400MHz gives 4.5milisec/sec or 4-5% overhead

1024*768*4/32*3*(1/4)*60
.04423680

52kB on the other hand is only 1664 lines but is obviously going to have
to do a lot of actual memory writes also for any modified cache line and
later a lot of reads to read back what was evicted. 




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


RE: [PATCH][v2][powerpc/85xx] P2020RDB Platform Support Added

2009-08-07 Thread Aggrwal Poonam-B10812
 

 -Original Message-
 From: Felix Radensky [mailto:fe...@embedded-sol.com] 
 Sent: Friday, August 07, 2009 4:42 PM
 To: Aggrwal Poonam-B10812
 Cc: linuxppc-...@ozlabs.org
 Subject: Re: [PATCH][v2][powerpc/85xx] P2020RDB Platform Support Added
 
 Hi, Poonam
 
 See some more comments below.
 
 Poonam Aggrwal wrote:
  Adds P2020RDB basic support in linux.
  Overview of P2020RDB platform
  - DDR
DDR2 1G
  - NOR Flash
16MByte
  - NAND Flash
32MByte
  - 3 Ethernet interfaces
1) etSEC1
  - RGMII
  - connected to a 5 port Vitesse Switch(VSC7385)
  - Switch is memory mapped through eLBC interface(CS#2)
  - IRQ1
2) etSEC2
  - SGMII
  - connected to VSC8221
  - IRQ2
3) etSEC3
  - RGMII
  - connected to VSC8641
  - IRQ3
  - 2 1X PCIe interfaces
  - SD/MMC ,USB
  - SPI EEPROM
  - Serial I2C EEPROM
  
  Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
  ---
  based on 
  http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
  incorporated Felix feedback regarding the partition names.
  fixed the vitesse switch ranges entry in device tree.
   arch/powerpc/boot/dts/p2020rdb.dts|  586 
 +
   arch/powerpc/configs/mpc85xx_defconfig|1 +
   arch/powerpc/platforms/85xx/Kconfig   |9 +
   arch/powerpc/platforms/85xx/Makefile  |3 +-
   arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  141 +++
   5 files changed, 739 insertions(+), 1 deletions(-)  create mode 
  100644 arch/powerpc/boot/dts/p2020rdb.dts
   create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c
  
  diff --git a/arch/powerpc/boot/dts/p2020rdb.dts 
  b/arch/powerpc/boot/dts/p2020rdb.dts
  new file mode 100644
  index 000..617029f
  --- /dev/null
  +++ b/arch/powerpc/boot/dts/p2020rdb.dts
  @@ -0,0 +1,586 @@
  +/*
  + * P2020 RDB Device Tree Source
  + *
  + * Copyright 2009 Freescale Semiconductor Inc.
  + *
  + * This program is free software; you can redistribute  it and/or 
  +modify it
  + * under  the terms of  the GNU General  Public License as 
 published 
  +by the
  + * Free Software Foundation;  either version 2 of the  License, or 
  +(at your
  + * option) any later version.
  + */
  +
  +/dts-v1/;
  +/ {
  +   model = fsl,P2020;
  +   compatible = fsl,P2020RDB;
  +   #address-cells = 2;
  +   #size-cells = 2;
  +
  +   aliases {
  +   ethernet0 = enet0;
  +   ethernet1 = enet1;
  +   ethernet2 = enet2;
  +   serial0 = serial0;
  +   serial1 = serial1;
  +   pci0 = pci0;
  +   pci1 = pci1;
  +   };
  +
  +   cpus {
  +   #address-cells = 1;
  +   #size-cells = 0;
  +
  +   PowerPC,p2...@0 {
  +   device_type = cpu;
  +   reg = 0x0;
  +   next-level-cache = L2;
  +   };
  +
  +   PowerPC,p2...@1 {
  +   device_type = cpu;
  +   reg = 0x1;
  +   next-level-cache = L2;
  +   };
  +   };
  +
  +   memory {
  +   device_type = memory;
  +   };
  +
  +   local...@ffe05000 {
  +   #address-cells = 2;
  +   #size-cells = 1;
  +   compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
  +   reg = 0 0xffe05000 0 0x1000;
  +   interrupts = 19 2;
  +   interrupt-parent = mpic;
  +
  +   /* NOR and NAND Flashes */
  +   ranges = 0x0 0x0 0x0 0xef00 0x0100
  + 0x1 0x0 0x0 0xffa0 0x0004
  + 0x2 0x0 0x0 0xffb0 0x0002;
  +
  +   n...@0,0 {
  +   #address-cells = 1;
  +   #size-cells = 1;
  +   compatible = cfi-flash;
  +   reg = 0x0 0x0 0x100;
  +   bank-width = 2;
  +   device-width = 1;
  +
  +   partit...@0 {
  +   /* This location must not be altered  */
  +   /* 256KB for Vitesse 7385 
 Switch firmware */
  +   reg = 0x0 0x0004;
  +   label = NOR (RO) Vitesse-7385 
 Firmware;
  +   read-only;
  +   };
  +
  +   partit...@4 {
  +   /* 256KB for DTB Image */
  +   reg = 0x0004 0x0004;
  +   label = NOR (RO) DTB Image;
  +   read-only;
  +   };
  +
  +   partit...@8 {
  +   /* 3.5 MB for Linux Kernel Image */
  +   reg = 0x0008 0x0038;
  +   label = NOR (RO) Linux Kernel Image;
  +   read-only;
  +   };
  +
  +   

Re: [PATCH] Do not inline putprops function

2009-08-07 Thread M. Mohan Kumar
Hi,

After enabling EARLY_DEBUG (and DEBUG in some of the files in
arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
byte alignment: 

# ./kexec -e
Starting new kernel
console [udbg0] enabled
 - early_setup(), dt_ptr: 0x7723000
 - early_init_devtree(c7723000)
Invalid tag 5 scanning flattened device tree !
search chosen, depth: 0, uname:
Invalid tag 5 scanning flattened device tree !
dt_root_size_cells = 2
dt_root_addr_cells = 2
Invalid tag 5 scanning flattened device tree !
reserving: 128c000 - 5ec1f7
reserving: 7734000 - 8cc000
reserving: 7723000 - f698
Phys. mem: 0
- move_device_tree
- move_device_tree
Scanning CPUs ...
Invalid tag 5 scanning flattened device tree !
 - early_init_devtree()
Probing machine type ...
  pSeries ...
No suitable machine found !


So device-tree is getting corrupted when dtstruct variable is not aligned to
8 byte variable. This problem is not seen with gcc-3.4. Is it compiler
issue? or bug in the code.

Regards,
M. Mohan Kumar.

On Fri, Aug 07, 2009 at 12:24:20AM +1000, Michael Ellerman wrote:
 On Wed, 2009-08-05 at 22:19 +0530, M. Mohan Kumar wrote:
  Hi,
  
  When I align the dtstruct variable to 8 bytes, I am able to invoke kdump.
  
  When the line
  static unsigned dtstruct[TREEWORDS], *dt;
  changed to 
  static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
  
  kexec-tool works.
 
 Hmm, odd.
 
 Can you check how it's aligned without your change? ie. in the original
 binary, is it 4 byte aligned?
 
 When you make the change, is the only thing that changes in the binary
 the alignedness of dtstruct, or does it cause other things to move
 around?
 
 I don't think an unaligned dt blob should have any effect on the kernel,
 ie. it should copy it in fine, but I'd have to look at the code.
 
 cheers


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


Re: [PATCH] Do not inline putprops function

2009-08-07 Thread M. Mohan Kumar
On Fri, Aug 07, 2009 at 08:05:49PM +0530, M. Mohan Kumar wrote:
 Hi,
 
 After enabling EARLY_DEBUG (and DEBUG in some of the files in
 arch/powerpc/kernel directory), without forcing the dtstruct variable to 8
 byte alignment: 
 
 # ./kexec -e
 Starting new kernel
 console [udbg0] enabled
  - early_setup(), dt_ptr: 0x7723000
  - early_init_devtree(c7723000)
 Invalid tag 5 scanning flattened device tree !
 search chosen, depth: 0, uname:
 Invalid tag 5 scanning flattened device tree !
 dt_root_size_cells = 2
 dt_root_addr_cells = 2
 Invalid tag 5 scanning flattened device tree !
 reserving: 128c000 - 5ec1f7
 reserving: 7734000 - 8cc000
 reserving: 7723000 - f698
 Phys. mem: 0
 - move_device_tree
 - move_device_tree
 Scanning CPUs ...
 Invalid tag 5 scanning flattened device tree !
  - early_init_devtree()
 Probing machine type ...
   pSeries ...
 No suitable machine found !
 
 
 So device-tree is getting corrupted when dtstruct variable is not aligned to
 8 byte variable. This problem is not seen with gcc-3.4. Is it compiler
 issue? or bug in the code.
 

I tried writing the device tree to a binary file with and without dt_len and
compared the files after hexdump:

 0001 2f00   0003  0004  0001 2f00  
 0003  0004
   0002  0003  0004    0002 
 0003  0004
 000f  0002  0003  0004  000f  0002 
 0003  0004
 001b 3ef1 4800  0003  000d  001b 3ef1 4800 
 0003  000d
 002b   4942 4d2c 3931 3135   |  002b 4942 4d2c 
3931 3135 2d35 3035
2d35 3035    0003  0005   |    0003 
 0005  0036

Regards,
M. Mohan Kumar






 
 On Fri, Aug 07, 2009 at 12:24:20AM +1000, Michael Ellerman wrote:
  On Wed, 2009-08-05 at 22:19 +0530, M. Mohan Kumar wrote:
   Hi,
   
   When I align the dtstruct variable to 8 bytes, I am able to invoke kdump.
   
   When the line
 static unsigned dtstruct[TREEWORDS], *dt;
   changed to 
 static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
   
   kexec-tool works.
  
  Hmm, odd.
  
  Can you check how it's aligned without your change? ie. in the original
  binary, is it 4 byte aligned?
  
  When you make the change, is the only thing that changes in the binary
  the alignedness of dtstruct, or does it cause other things to move
  around?
  
  I don't think an unaligned dt blob should have any effect on the kernel,
  ie. it should copy it in fine, but I'd have to look at the code.
  
  cheers
 
 
 
 ___
 kexec mailing list
 ke...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: ethernet phy attached to wrong driver

2009-08-07 Thread Detlev Zundel
Hi Stefan,

 I'm having trouble with my Ethernet device on a TQM5200 based board with
 LXT971 Phy. I'm running U-Boot 2009.03 and a Kernel 2.6.30.

 When doing a ping under U-Boot before booting into Linux, Ethernet works
 fine in Linux also. Dmesg reads:
 [  262.369444] net eth0: Using PHY at MDIO address 0
 [  263.265903] net eth0: attached phy 0 to driver LXT971

 But if I start Linux without prior use of the fec under U-Boot, Ethernet
 is not working in Linux. The wrong drivers seems to be attached to the
 phy. Dmesg reads:
 [2.068285] net eth0: Using PHY at MDIO address 0
 [2.964774] net eth0: attached phy 0 to driver Generic PHY
   ^^^
 Is there a bootarg to tell linux which driver to use? Any ideas what I'm
 doing wrong?

I cannot reproduce this problem with a tqm5200/stk52xx combination.
Linux always happily uses a genric PHY, irrelevant if I use networking
in U-Boot.

Cheers
  Detlev

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

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


[v3][PATCH][powerpc/85xx] P2020RDB Platform Support Added

2009-08-07 Thread Poonam Aggrwal
Adds P2020RDB basic support in linux.
Overview of P2020RDB platform
- DDR
  DDR2 1G
- NOR Flash
  16MByte
- NAND Flash
  32MByte
- 3 Ethernet interfaces
  1) etSEC1
- RGMII
- connected to a 5 port Vitesse Switch(VSC7385)
- Switch is memory mapped through eLBC interface(CS#2)
- IRQ1
  2) etSEC2
- SGMII
- connected to VSC8221
- IRQ2
  3) etSEC3
- RGMII
- connected to VSC8641
- IRQ3
- 2 1X PCIe interfaces
- SD/MMC ,USB
- SPI EEPROM
- Serial I2C EEPROM

Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
---
based on http://www.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
Incorporated more feedback from Felix
 arch/powerpc/boot/dts/p2020rdb.dts|  586 +
 arch/powerpc/configs/mpc85xx_defconfig|1 +
 arch/powerpc/platforms/85xx/Kconfig   |9 +
 arch/powerpc/platforms/85xx/Makefile  |3 +-
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |  141 +++
 5 files changed, 739 insertions(+), 1 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p2020rdb.dts
 create mode 100644 arch/powerpc/platforms/85xx/mpc85xx_rdb.c

diff --git a/arch/powerpc/boot/dts/p2020rdb.dts 
b/arch/powerpc/boot/dts/p2020rdb.dts
new file mode 100644
index 000..da4cb0d
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -0,0 +1,586 @@
+/*
+ * P2020 RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+   model = fsl,P2020;
+   compatible = fsl,P2020RDB;
+   #address-cells = 2;
+   #size-cells = 2;
+
+   aliases {
+   ethernet0 = enet0;
+   ethernet1 = enet1;
+   ethernet2 = enet2;
+   serial0 = serial0;
+   serial1 = serial1;
+   pci0 = pci0;
+   pci1 = pci1;
+   };
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   PowerPC,p2...@0 {
+   device_type = cpu;
+   reg = 0x0;
+   next-level-cache = L2;
+   };
+
+   PowerPC,p2...@1 {
+   device_type = cpu;
+   reg = 0x1;
+   next-level-cache = L2;
+   };
+   };
+
+   memory {
+   device_type = memory;
+   };
+
+   local...@ffe05000 {
+   #address-cells = 2;
+   #size-cells = 1;
+   compatible = fsl,p2020-elbc, fsl,elbc, simple-bus;
+   reg = 0 0xffe05000 0 0x1000;
+   interrupts = 19 2;
+   interrupt-parent = mpic;
+
+   /* NOR and NAND Flashes */
+   ranges = 0x0 0x0 0x0 0xef00 0x0100
+ 0x1 0x0 0x0 0xffa0 0x0004
+ 0x2 0x0 0x0 0xffb0 0x0002;
+
+   n...@0,0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = cfi-flash;
+   reg = 0x0 0x0 0x100;
+   bank-width = 2;
+   device-width = 1;
+
+   partit...@0 {
+   /* This location must not be altered  */
+   /* 256KB for Vitesse 7385 Switch firmware */
+   reg = 0x0 0x0004;
+   label = NOR (RO) Vitesse-7385 Firmware;
+   read-only;
+   };
+
+   partit...@4 {
+   /* 256KB for DTB Image */
+   reg = 0x0004 0x0004;
+   label = NOR (RO) DTB Image;
+   read-only;
+   };
+
+   partit...@8 {
+   /* 3.5 MB for Linux Kernel Image */
+   reg = 0x0008 0x0038;
+   label = NOR (RO) Linux Kernel Image;
+   read-only;
+   };
+
+   partit...@40 {
+   /* 11MB for JFFS2 based Root file System */
+   reg = 0x0040 0x00b0;
+   label = NOR (RW) JFFS2 Root File System;
+   };
+
+   partit...@f0 {
+

Re: sequoia: The final kernel image would overwrite the device tree

2009-08-07 Thread Geert Uytterhoeven
On Tue, 28 Jul 2009, Geert Uytterhoeven wrote:
 Current kernel (2.6.31-rc4) fails to boot on sequoia:
 
 | ## Booting image at 0010 ...
 |Image Name:   Linux-2.6.31-rc4-3-g52c6890-
 |Image Type:   PowerPC Linux Kernel Image (gzip compressed)
 |Data Size:1680490 Bytes =  1.6 MB
 |Load Address: 0040
 |Entry Point:  00400458
 |Verifying Checksum ... OK
 |Uncompressing Kernel Image ... OK
 | CPU clock-frequency - 0x27bc86a4 (667MHz)
 | CPU timebase-frequency - 0x27bc86a4 (667MHz)
 | /plb: clock-frequency - 9ef21a9 (167MHz)
 | /plb/opb: clock-frequency - 4f790d4 (83MHz)
 | /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz)
 | /plb/opb/ser...@ef600300: clock-frequency - a8c000 (11MHz)
 | /plb/opb/ser...@ef600400: clock-frequency - a8c000 (11MHz)
 | /plb/opb/ser...@ef600500: clock-frequency - 42ecac (4MHz)
 | /plb/opb/ser...@ef600600: clock-frequency - 42ecac (4MHz)
 | Memory - 0x0 0x0 0x000 (255MB)
 | ethernet0: local-mac-address - 00:10:ec:00:f1:df
 | ethernet1: local-mac-address - 00:10:ec:80:f1:df
 | 
 | zImage starting: loaded at 0x0040 (sp: 0x0ff2ba18)
 | Allocating 0x85e77c bytes for kernel ...
 | The final kernel image would overwrite the device tree?
 
 Git bisect told me the bad guy is:
 
 | commit 5d38902c483881645ba16058cffaa478b81e5cfa
 | Author: Benjamin Herrenschmidt b...@kernel.crashing.org
 | Date:   Wed Jun 17 17:43:59 2009 +
 | 
 | powerpc: Add irqtrace support for 32-bit powerpc
 
 However, disabling CONFIG_PROVE_LOCKING also fixes the problem.

I did some more investigations.

If CONFIG_PROVE_LOCKING is not set:

| zImage starting: loaded at 0x0040 (sp: 0x0ff2b670)
| Allocating 0x74a764 bytes for kernel ...
| platform_ops.vmlinux_alloc = 0x
| _end = 0x78e000
| gunzipping (0x - 0x0040e000:0x00781b34)...done 0x360460 bytes

and the rest of the kernel boots (note: it hangs later on with BUG: spinlock
lockup on CPU#0, swapper/1, cf8b6908 with today's kernel, will look into
that later).

However, nm says _end = c074b000?


If CONFIG_PROVE_LOCKING=y:

| zImage starting: loaded at 0x0040 (sp: 0x0ff2ba18)
| Allocating 0x85e784 bytes for kernel ...
| platform_ops.vmlinux_alloc = 0x
| _end = 0x792000
| The final kernel image would overwrite the device tree?

and it reboots.

However, nm says _end = c085f000.

So in both cases _end is not correct in arch/powerpc/boot/main.c:prep_kernel()?
But depending on CONFIG_PROVE_LOCKING, the test for
((unsigned long)_end  ei.memsize) gives different results, and the kernel
boots or doesn't boot?

  
With kind regards,

Geert Uytterhoeven
Software Architect
Techsoft Centre

Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:+32 (0)2 700 8453
Fax:  +32 (0)2 700 8622
E-mail:   geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


PSC clock divider

2009-08-07 Thread Jon Smirl
mpc52xx_set_psc_clkdiv() has problems. It take the clk divider as a
parameter. But this divisor is not always gettting calculated
correctly. My code in i2s was doing it wrong.

Take this snippet from the SPI driver, it just assumes a fsystem of
512Mhz. fsystem is 533Mhz on my boards.

/* default sysclk is 512MHz */
mclken_div = (mps-sysclk ? mps-sysclk : 51200) / MCLK;
mpc52xx_set_psc_clkdiv(psc_id, mclken_div);

Is it also not accounting for the hardware adding one to the divisor.

I've change i2s to this:

if (!fsystem) {
np = of_find_matching_node(NULL, 
mpc52xx_cdm_ids);
mpc52xx_cdm = of_iomap(np, 0);
fsystem = mpc5xxx_get_bus_frequency(np);
of_node_put(np);
val = in_be32(mpc52xx_cdm-rstcfg);
if (val  (1  5))
fsystem *= 8;
else
fsystem *= 4;
iounmap(mpc52xx_cdm);
}
clkdiv = fsystem / freq;
err = fsystem % freq;
if (err  freq / 2)
clkdiv++;

dev_dbg(psc_dma-dev, psc_i2s_set_sysclk(clkdiv %d 
freq error=%dHz)\n,
clkdiv, (fsystem / clkdiv - freq));

/* PSC is 1-6 */
/* Hardware adds 1 to divisor */
return mpc52xx_set_psc_clkdiv(psc_dma-id + 1, clkdiv - 
1);


Should I modify mpc52xx_set_psc_clkdiv() to take in a frequency and
them move this code into mpc52xx_common.c? That allows the sysclk
parameter to be eliminated for SPI.


-- 
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PSC clock divider

2009-08-07 Thread Grant Likely
On Fri, Aug 7, 2009 at 10:03 AM, Jon Smirljonsm...@gmail.com wrote:
 mpc52xx_set_psc_clkdiv() has problems. It take the clk divider as a
 parameter. But this divisor is not always gettting calculated
 correctly. My code in i2s was doing it wrong.

 Take this snippet from the SPI driver, it just assumes a fsystem of
 512Mhz. fsystem is 533Mhz on my boards.

        /* default sysclk is 512MHz */
        mclken_div = (mps-sysclk ? mps-sysclk : 51200) / MCLK;
        mpc52xx_set_psc_clkdiv(psc_id, mclken_div);

 Is it also not accounting for the hardware adding one to the divisor.

 I've change i2s to this:

                        if (!fsystem) {
                                np = of_find_matching_node(NULL, 
 mpc52xx_cdm_ids);
                                mpc52xx_cdm = of_iomap(np, 0);
                                fsystem = mpc5xxx_get_bus_frequency(np);
                                of_node_put(np);
                                val = in_be32(mpc52xx_cdm-rstcfg);
                                if (val  (1  5))
                                        fsystem *= 8;
                                else
                                        fsystem *= 4;
                                iounmap(mpc52xx_cdm);
                        }
                        clkdiv = fsystem / freq;
                        err = fsystem % freq;
                        if (err  freq / 2)
                                clkdiv++;

                        dev_dbg(psc_dma-dev, psc_i2s_set_sysclk(clkdiv %d 
 freq error=%dHz)\n,
                                        clkdiv, (fsystem / clkdiv - freq));

                        /* PSC is 1-6 */
                        /* Hardware adds 1 to divisor */
                        return mpc52xx_set_psc_clkdiv(psc_dma-id + 1, clkdiv 
 - 1);


 Should I modify mpc52xx_set_psc_clkdiv() to take in a frequency and
 them move this code into mpc52xx_common.c? That allows the sysclk
 parameter to be eliminated for SPI.

Yes, please do.

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 0/4] sdhci-of: Some fixes for high-speed and 4-bit SD cards

2009-08-07 Thread Anton Vorontsov
Hi all,

Finally I've got a bunch of SD cards to test eSDHC in various ways,
and more importantly now I have a lot of SDHS cards. ;-)

So, here are few fixes that make eSDHC work flawlessly on MPC83xx
SOCs with all SD and MMC cards that I have.

On MPC85xx (namely MPC8536 and MPC8569) SOCs there is one issue:
the cards can be detected and read just fine, but writing doesn't
work (no interrupts received). I'm currently investigating this.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/4] sdhci-of: Fix SD clock calculation

2009-08-07 Thread Anton Vorontsov
Linear divisor's values in a register start at 0 (zero means
divide by 1). Before this patch the code didn't account that
fact, so SD cards were running underclocked.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 9088443..92b5667 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -136,6 +136,7 @@ static void esdhc_set_clock(struct sdhci_host *host, 
unsigned int clock)
}
 
pre_div = 1;
+   div--;
 
setbits32(host-ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
  ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN |
-- 
1.6.3.3

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


[PATCH 2/4] sdhci-of: Avoid writing reserved bits into host control register

2009-08-07 Thread Anton Vorontsov
SDHCI core tries to write HISPD bit into the host control register,
but the eSDHC controllers don't have that bit, and that causes
all sorts of misbehaviour when using 4-bit mode capable SD cards.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 92b5667..8440fd9 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -48,6 +48,8 @@ struct sdhci_of_host {
 #define ESDHC_CLOCK_HCKEN  0x0002
 #define ESDHC_CLOCK_IPGEN  0x0001
 
+#define ESDHC_HOST_CONTROL_RES 0x05
+
 static u32 esdhc_readl(struct sdhci_host *host, int reg)
 {
return in_be32(host-ioaddr + reg);
@@ -109,6 +111,10 @@ static void esdhc_writeb(struct sdhci_host *host, u8 val, 
int reg)
int base = reg  ~0x3;
int shift = (reg  0x3) * 8;
 
+   /* Prevent SDHCI core from writing reserved bits (e.g. HISPD). */
+   if (reg == SDHCI_HOST_CONTROL)
+   val = ~ESDHC_HOST_CONTROL_RES;
+
clrsetbits_be32(host-ioaddr + base , 0xff  shift, val  shift);
 }
 
-- 
1.6.3.3

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


[PATCH 3/4] sdhci-of: Fix high-speed cards recognition

2009-08-07 Thread Anton Vorontsov
eSDHC fails to recognize some SDHS cards, throwing timeout errors:

  mmc0: error -110 whilst initialising SD card

That's because we calculate timeout value in a wrong way: on eSDHC
hosts the timeout clock is derivied from the SD clock, which is set
dynamically.

This patch fixes the issue by introducing and implementing
DYNAMIC_TIMEOUT_CLOCK quirk for sdhci-of driver.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |5 ++---
 drivers/mmc/host/sdhci.c|4 
 drivers/mmc/host/sdhci.h|2 ++
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 8440fd9..b6ff2e8 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -174,9 +174,7 @@ static unsigned int esdhc_get_min_clock(struct sdhci_host 
*host)
 
 static unsigned int esdhc_get_timeout_clock(struct sdhci_host *host)
 {
-   struct sdhci_of_host *of_host = sdhci_priv(host);
-
-   return of_host-clock / 1000;
+   return host-clock / 1000;
 }
 
 static struct sdhci_of_data sdhci_esdhc = {
@@ -185,6 +183,7 @@ static struct sdhci_of_data sdhci_esdhc = {
  SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
  SDHCI_QUIRK_NO_BUSY_IRQ |
  SDHCI_QUIRK_NONSTANDARD_CLOCK |
+ SDHCI_QUIRK_DYNAMIC_TIMEOUT_CLOCK |
  SDHCI_QUIRK_PIO_NEEDS_DELAY |
  SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET |
  SDHCI_QUIRK_NO_CARD_NO_RESET,
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index fc96f8c..0f273fe 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -591,6 +591,10 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, 
struct mmc_data *data)
target_timeout = data-timeout_ns / 1000 +
data-timeout_clks / host-clock;
 
+   if (host-quirks  SDHCI_QUIRK_DYNAMIC_TIMEOUT_CLOCK 
+   host-ops-get_timeout_clock)
+   host-timeout_clk = host-ops-get_timeout_clock(host);
+
/*
 * Figure out needed cycles.
 * We do this in steps in order to fit inside a 32 bit int.
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index c77e9ff..44b1dcc 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -232,6 +232,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_FORCE_1_BIT_DATA   (122)
 /* Controller needs 10ms delay between applying power and clock */
 #define SDHCI_QUIRK_DELAY_AFTER_POWER  (123)
+/* Controller has dynamic timeout clock management */
+#define SDHCI_QUIRK_DYNAMIC_TIMEOUT_CLOCK  (124)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
-- 
1.6.3.3

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


[PATCH 4/4] sdhci-of: Cleanup eSDHC's set_clock() a little bit

2009-08-07 Thread Anton Vorontsov
- Get rid of incomprehensible if { for { if } } construction for the
  exponential divisor calculation. The first if statement isn't correct
  at all, since it should check for host-max_clk / pre_div / 16 
  clock. The error doesn't cause any bugs because the check in the for
  loop does the right thing, and so the outer check becomes useless;

- For the linear divisor do the same: a single while statement is more
  readable than for + if construction;

- Add dev_dbg() that prints desired and actual clock frequency.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |   19 ---
 1 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index b6ff2e8..bbdd468 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -120,8 +120,8 @@ static void esdhc_writeb(struct sdhci_host *host, u8 val, 
int reg)
 
 static void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
 {
-   int div;
int pre_div = 2;
+   int div = 1;
 
clrbits32(host-ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
  ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK);
@@ -129,17 +129,14 @@ static void esdhc_set_clock(struct sdhci_host *host, 
unsigned int clock)
if (clock == 0)
goto out;
 
-   if (host-max_clk / 16  clock) {
-   for (; pre_div  256; pre_div *= 2) {
-   if (host-max_clk / pre_div  clock * 16)
-   break;
-   }
-   }
+   while (host-max_clk / pre_div / 16  clock  pre_div  256)
+   pre_div *= 2;
 
-   for (div = 1; div = 16; div++) {
-   if (host-max_clk / (div * pre_div) = clock)
-   break;
-   }
+   while (host-max_clk / pre_div / div  clock  div  16)
+   div++;
+
+   dev_dbg(mmc_dev(host-mmc), desired SD clock: %d, actual: %d\n,
+   clock, host-max_clk / pre_div / div);
 
pre_div = 1;
div--;
-- 
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PSC clock divider

2009-08-07 Thread Grant Likely
On Fri, Aug 7, 2009 at 10:34 AM, Jon Smirljonsm...@gmail.com wrote:
 On Fri, Aug 7, 2009 at 12:15 PM, Grant Likelygrant.lik...@secretlab.ca 
 wrote:
 Should I modify mpc52xx_set_psc_clkdiv() to take in a frequency and
 them move this code into mpc52xx_common.c? That allows the sysclk
 parameter to be eliminated for SPI.

 Yes, please do.

 Can mpc5xxx_clocks.c be eliminated and this function:

 mpc5xxx_get_bus_frequency(struct device_node *node)

 be moved into mpc52cc_common.c?

No.  mpc5xxx_get_bus_frequency is not mpc5200 specific.  It is used by
mpc5121 also.

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 0/4] sdhci-of: Some fixes for high-speed and 4-bit SD cards

2009-08-07 Thread Anton Vorontsov
On Fri, Aug 07, 2009 at 08:39:40PM +0400, Anton Vorontsov wrote:
 Hi all,
 
 Finally I've got a bunch of SD cards to test eSDHC in various ways,
 and more importantly now I have a lot of SDHS cards. ;-)
 
 So, here are few fixes that make eSDHC work flawlessly on MPC83xx
 SOCs with all SD and MMC cards that I have.
 
 On MPC85xx (namely MPC8536 and MPC8569) SOCs there is one issue:
 the cards can be detected and read just fine, but writing doesn't
 work (no interrupts received). I'm currently investigating this.

Solved. It appears that eSDHC on MPC85xx has a normal write-protect
reporting. And eSDHC actually checks the WP pin, thus doesn't let
anybody to do any writes... I'll make some additional patches and
will send v2 soon.

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.

2009-08-07 Thread Jon Smirl
Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.
Previous code had errors or used a constant. This versions computes
the right clock based on the xtal and register settings.
---
 arch/powerpc/include/asm/mpc52xx.h   |2 +-
 arch/powerpc/platforms/52xx/mpc52xx_common.c |   26 --
 drivers/spi/mpc52xx_psc_spi.c|8 +---
 sound/soc/fsl/mpc5200_psc_i2s.c  |   11 +--
 4 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index cadd398..1ca8a0e 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -285,7 +285,7 @@ struct mpc52xx_rtc {
 extern void mpc5200_setup_xlb_arbiter(void);
 extern void mpc52xx_declare_of_platform_devices(void);
 extern void mpc52xx_map_common_devices(void);
-extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
+extern int mpc52xx_set_psc_clkdiv(int psc_id, int freq);
 extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
 extern void mpc52xx_restart(char *cmd);
 
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c 
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index a46bad0..f81fb03 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -110,6 +110,8 @@ static struct of_device_id mpc52xx_cdm_ids[] __initdata = {
{}
 };
 
+static u32 fsystem; /* fsystem clock on mpc5200 */
+
 /**
  * mpc52xx_map_common_devices: iomap devices required by common code
  */
@@ -117,6 +119,7 @@ void __init
 mpc52xx_map_common_devices(void)
 {
struct device_node *np;
+   u32 val;
 
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
 * possibly from a interrupt context. wdt is only implement
@@ -133,8 +136,16 @@ mpc52xx_map_common_devices(void)
 
/* Clock Distribution Module, used by PSC clock setting function */
np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
+   fsystem = mpc5xxx_get_bus_frequency(np);
mpc52xx_cdm = of_iomap(np, 0);
of_node_put(np);
+
+   /* compute fsystem, it is either 4 or 8 times the bus freq */
+   val = in_be32(mpc52xx_cdm-rstcfg);
+   if (val  (1  5))
+   fsystem *= 8;
+   else
+   fsystem *= 4;
 }
 
 /**
@@ -143,17 +154,28 @@ mpc52xx_map_common_devices(void)
  * @psc_id: id of psc port; must be 1,2,3 or 6
  * @clkdiv: clock divider value to put into CDM PSC register.
  */
-int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv)
+int mpc52xx_set_psc_clkdiv(int psc_id, int freq)
 {
unsigned long flags;
u16 __iomem *reg;
u32 val;
-   u32 mask;
+   u32 mask, clkdiv, err;
u32 mclken_div;
 
if (!mpc52xx_cdm)
return -ENODEV;
 
+   /* figure out the closest frequency the hardware can make */
+   clkdiv = fsystem / freq;
+   err = fsystem % freq;
+   if (err  freq / 2)
+   clkdiv++;
+   /* hardware is not very flexible, there will be significant error */
+   /* frequency error = fsystem / clkdiv - freq; */
+
+   /* hardware adds one to the divisor */
+   clkdiv -= 1;
+
mclken_div = 0x8000 | (clkdiv  0x1FF);
switch (psc_id) {
case 1: reg = mpc52xx_cdm-mclken_div_psc1; mask = 0x20; break;
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index d2a04d6..5c8e621 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -33,7 +33,6 @@
 struct mpc52xx_psc_spi {
/* fsl_spi_platform data */
void (*cs_control)(struct spi_device *spi, bool on);
-   u32 sysclk;
 
/* driver internal data */
struct mpc52xx_psc __iomem *psc;
@@ -313,12 +312,9 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct 
mpc52xx_psc_spi *mps)
 {
struct mpc52xx_psc __iomem *psc = mps-psc;
struct mpc52xx_psc_fifo __iomem *fifo = mps-fifo;
-   u32 mclken_div;
int ret = 0;
 
-   /* default sysclk is 512MHz */
-   mclken_div = (mps-sysclk ? mps-sysclk : 51200) / MCLK;
-   mpc52xx_set_psc_clkdiv(psc_id, mclken_div);
+   mpc52xx_set_psc_clkdiv(psc_id, MCLK);
 
/* Reset the PSC into a known state */
out_8(psc-command, MPC52xx_PSC_RST_RX);
@@ -383,12 +379,10 @@ static int __init mpc52xx_psc_spi_do_probe(struct 
of_device *op, u32 regaddr,
dev_warn(op-dev, probe called without platform data, no 
cs_control function will be called\n);
mps-cs_control = NULL;
-   mps-sysclk = 0;
master-bus_num = bus_num;
master-num_chipselect = 255;
} else {
mps-cs_control = pdata-cs_control;
-   mps-sysclk = pdata-sysclk;
master-bus_num = pdata-bus_num;
master-num_chipselect = 

Re: [PATCH 3/4] sdhci-of: Fix high-speed cards recognition

2009-08-07 Thread Anton Vorontsov
On Fri, Aug 07, 2009 at 06:08:59PM +0100, David Vrabel wrote:
 Anton Vorontsov wrote:
  eSDHC fails to recognize some SDHS cards, throwing timeout errors:
  
mmc0: error -110 whilst initialising SD card
  
  That's because we calculate timeout value in a wrong way: on eSDHC
  hosts the timeout clock is derivied from the SD clock, which is set
  dynamically.
 
 I've seen an reference design for an SDHC controller do this also.

Thanks for the information!

  +/* Controller has dynamic timeout clock management */
  +#define SDHCI_QUIRK_DYNAMIC_TIMEOUT_CLOCK  (124)
 
 This comment and define would be better if it matched terms used in the
 spec.  Suggest:
 
 /* Controller uses SDCLK instead of TMCLK for data timeouts. */
 #define SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK  (1  24)

Yeah, if it's somewhat common scheme, then it makes sense to name the
quirk that way.

Thanks,

-- 
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.

2009-08-07 Thread Grant Likely
On Fri, Aug 7, 2009 at 12:41 PM, Jon Smirljonsm...@gmail.com wrote:
 Use clock freqency from the device tree to calculate correct MPC5200 PSC 
 clock.
 Previous code had errors or used a constant. This versions computes
 the right clock based on the xtal and register settings.

Looks good to me; one comment below:

 ---
  arch/powerpc/include/asm/mpc52xx.h           |    2 +-
  arch/powerpc/platforms/52xx/mpc52xx_common.c |   26 
 --
  drivers/spi/mpc52xx_psc_spi.c                |    8 +---
  sound/soc/fsl/mpc5200_psc_i2s.c              |   11 +--
  4 files changed, 27 insertions(+), 20 deletions(-)

 diff --git a/arch/powerpc/include/asm/mpc52xx.h 
 b/arch/powerpc/include/asm/mpc52xx.h
 index cadd398..1ca8a0e 100644
 --- a/arch/powerpc/include/asm/mpc52xx.h
 +++ b/arch/powerpc/include/asm/mpc52xx.h
 @@ -285,7 +285,7 @@ struct mpc52xx_rtc {
  extern void mpc5200_setup_xlb_arbiter(void);
  extern void mpc52xx_declare_of_platform_devices(void);
  extern void mpc52xx_map_common_devices(void);
 -extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
 +extern int mpc52xx_set_psc_clkdiv(int psc_id, int freq);
  extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
  extern void mpc52xx_restart(char *cmd);

 diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c 
 b/arch/powerpc/platforms/52xx/mpc52xx_common.c
 index a46bad0..f81fb03 100644
 --- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
 +++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
 @@ -110,6 +110,8 @@ static struct of_device_id mpc52xx_cdm_ids[] __initdata = 
 {
        {}
  };

 +static u32 fsystem; /* fsystem clock on mpc5200 */
 +

To protect against collisions with the global namespace, please name
this mpc5200_fsystem.

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 V2] Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.

2009-08-07 Thread Jon Smirl
Use clock freqency from the device tree to calculate correct MPC5200 PSC clock.
Previous code had errors or used a constant. This versions computes
the right clock based on the xtal and register settings.

Signed-off-by: Jon Smirl jonsm...@gmail.com
---
 arch/powerpc/include/asm/mpc52xx.h   |2 +-
 arch/powerpc/platforms/52xx/mpc52xx_common.c |   26 --
 drivers/spi/mpc52xx_psc_spi.c|8 +---
 sound/soc/fsl/mpc5200_psc_i2s.c  |   11 +--
 4 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index cadd398..1ca8a0e 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -285,7 +285,7 @@ struct mpc52xx_rtc {
 extern void mpc5200_setup_xlb_arbiter(void);
 extern void mpc52xx_declare_of_platform_devices(void);
 extern void mpc52xx_map_common_devices(void);
-extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
+extern int mpc52xx_set_psc_clkdiv(int psc_id, int freq);
 extern unsigned int mpc52xx_get_xtal_freq(struct device_node *node);
 extern void mpc52xx_restart(char *cmd);
 
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c 
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index a46bad0..8a19156 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -110,6 +110,8 @@ static struct of_device_id mpc52xx_cdm_ids[] __initdata = {
{}
 };
 
+static u32 mpc52xx_fsystem; /* fsystem clock on mpc5200 */
+
 /**
  * mpc52xx_map_common_devices: iomap devices required by common code
  */
@@ -117,6 +119,7 @@ void __init
 mpc52xx_map_common_devices(void)
 {
struct device_node *np;
+   u32 val;
 
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
 * possibly from a interrupt context. wdt is only implement
@@ -133,8 +136,16 @@ mpc52xx_map_common_devices(void)
 
/* Clock Distribution Module, used by PSC clock setting function */
np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
+   mpc52xx_fsystem = mpc5xxx_get_bus_frequency(np);
mpc52xx_cdm = of_iomap(np, 0);
of_node_put(np);
+
+   /* compute fsystem, it is either 4 or 8 times the bus freq */
+   val = in_be32(mpc52xx_cdm-rstcfg);
+   if (val  (1  5))
+   mpc52xx_fsystem *= 8;
+   else
+   mpc52xx_fsystem *= 4;
 }
 
 /**
@@ -143,17 +154,28 @@ mpc52xx_map_common_devices(void)
  * @psc_id: id of psc port; must be 1,2,3 or 6
  * @clkdiv: clock divider value to put into CDM PSC register.
  */
-int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv)
+int mpc52xx_set_psc_clkdiv(int psc_id, int freq)
 {
unsigned long flags;
u16 __iomem *reg;
u32 val;
-   u32 mask;
+   u32 mask, clkdiv, err;
u32 mclken_div;
 
if (!mpc52xx_cdm)
return -ENODEV;
 
+   /* figure out the closest frequency the hardware can make */
+   clkdiv = mpc52xx_fsystem / freq;
+   err = mpc52xx_fsystem % freq;
+   if (err  freq / 2)
+   clkdiv++;
+   /* hardware is not very flexible, there will be significant error */
+   /* frequency error = fsystem / clkdiv - freq; */
+
+   /* hardware adds one to the divisor */
+   clkdiv -= 1;
+
mclken_div = 0x8000 | (clkdiv  0x1FF);
switch (psc_id) {
case 1: reg = mpc52xx_cdm-mclken_div_psc1; mask = 0x20; break;
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index d2a04d6..5c8e621 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -33,7 +33,6 @@
 struct mpc52xx_psc_spi {
/* fsl_spi_platform data */
void (*cs_control)(struct spi_device *spi, bool on);
-   u32 sysclk;
 
/* driver internal data */
struct mpc52xx_psc __iomem *psc;
@@ -313,12 +312,9 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct 
mpc52xx_psc_spi *mps)
 {
struct mpc52xx_psc __iomem *psc = mps-psc;
struct mpc52xx_psc_fifo __iomem *fifo = mps-fifo;
-   u32 mclken_div;
int ret = 0;
 
-   /* default sysclk is 512MHz */
-   mclken_div = (mps-sysclk ? mps-sysclk : 51200) / MCLK;
-   mpc52xx_set_psc_clkdiv(psc_id, mclken_div);
+   mpc52xx_set_psc_clkdiv(psc_id, MCLK);
 
/* Reset the PSC into a known state */
out_8(psc-command, MPC52xx_PSC_RST_RX);
@@ -383,12 +379,10 @@ static int __init mpc52xx_psc_spi_do_probe(struct 
of_device *op, u32 regaddr,
dev_warn(op-dev, probe called without platform data, no 
cs_control function will be called\n);
mps-cs_control = NULL;
-   mps-sysclk = 0;
master-bus_num = bus_num;
master-num_chipselect = 255;
} else {
mps-cs_control = pdata-cs_control;
-   mps-sysclk = pdata-sysclk;
 

Re: Question about powerpc branch instructions

2009-08-07 Thread Scott Wood
On Fri, Aug 07, 2009 at 05:47:00PM +0900, HongWoo Lee wrote:
 #2: Is b similar to the jmp in x86 ? 

Yes, specifically a relative near jmp.

 and bl is similar to the call in x86 ?

Sort of (and again, specifically a relative near call).  Call on x86
pushes the return address on the stack, while bl on powerpc puts the
return address in a special register (lr) that the called function has to
save on the stack itself if it wants to call another function.

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


Re: 5121 cache handling.

2009-08-07 Thread Scott Wood
On Fri, Aug 07, 2009 at 02:53:52PM +0200, Kenneth Johansson wrote:
 on 5121 there is a e300 core that unfortunately is connected to the rest
 of the SOC with a bus that do not support coherency.
 
 solution for many driver has been to use uncached memory. But for the
 framebuffer that is not going to work as the performance impact of doing
 graphics operations on uncached memory is to large.
 
 currently the solution is to flush the cache in the interrupt
 handler. 
 
 #if defined(CONFIG_NOT_COHERENT_CACHE)
 int i;
 unsigned int *ptr;
 ptr  = coherence_data;
 for (i = 0; i  1024*8; i++)
 *ptr++ = 0;
 #endif
 
 Now this apparently is not enough on a e300 core that has a PLRU cache
 replacement algorithm. but what is the optimal solution? 

Which driver (in which kernel) are you looking at?

drivers/video/fsl-diu-fb.c in current mainline has properly sized
coherence data.  It also does a dcbz (on unused data) instead of loads,
as it's apparently faster (though I'd think you'd get more traffic
flushing those zeroes out later on, compared to a clean line that can
just be discarded).

 should not the framebuffer be marked as cache write through. that is the
 W bit should be set in the tlb mapping. Why is this not done ? is that
 feature also not working on 5121 ??

It probably would have been too slow.

 problem with doing it over just the framebuffer is that a 1024x768
 buffer is 98304 cache lines it's going to take a considerable time to
 do. 

That's why we flush the whole cache instead.

 how many cycles does it take per cache line if we never get a hit ??
 3cycles at 400MHz gives 4.5milisec/sec or 4-5% overhead
 
 1024*768*4/32*3*(1/4)*60
 .04423680
 
 52kB on the other hand is only 1664 lines but is obviously going to have
 to do a lot of actual memory writes also for any modified cache line and
 later a lot of reads to read back what was evicted. 

During periods of framebuffer activity, a lot of those cache lines likely
are for the framebuffer, so you'll still have those same issues.

If current performance is inadequate, you may want to consider using the
MMU and timers to figure out when the framebuffer is active, and stop the
sync when it's not.

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


[PATCH v2 0/7] sdhci-of: Some fixes for high-speed and 4-bit SD cards

2009-08-07 Thread Anton Vorontsov
In v2:

- Addressed David Vrabel's comments;
- New patches added:
  powerpc: Introduce and document sdhci,wp-inverted property for eSDHC
  sdhci-of: Don't hard-code inverted write-protect quirk
  powerpc/85xx: Add eSDHC support for MPC8536DS boards
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 1/7] sdhci-of: Fix SD clock calculation

2009-08-07 Thread Anton Vorontsov
Linear divisor's values in a register start at 0 (zero means
divide by 1). Before this patch the code didn't account that
fact, so SD cards were running underclocked.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 9088443..92b5667 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -136,6 +136,7 @@ static void esdhc_set_clock(struct sdhci_host *host, 
unsigned int clock)
}
 
pre_div = 1;
+   div--;
 
setbits32(host-ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
  ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN |
-- 
1.6.3.3

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


[PATCH 2/7] sdhci-of: Avoid writing reserved bits into host control register

2009-08-07 Thread Anton Vorontsov
SDHCI core tries to write HISPD bit into the host control register,
but the eSDHC controllers don't have that bit, and that causes
all sorts of misbehaviour when using 4-bit mode capable SD cards.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 92b5667..8440fd9 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -48,6 +48,8 @@ struct sdhci_of_host {
 #define ESDHC_CLOCK_HCKEN  0x0002
 #define ESDHC_CLOCK_IPGEN  0x0001
 
+#define ESDHC_HOST_CONTROL_RES 0x05
+
 static u32 esdhc_readl(struct sdhci_host *host, int reg)
 {
return in_be32(host-ioaddr + reg);
@@ -109,6 +111,10 @@ static void esdhc_writeb(struct sdhci_host *host, u8 val, 
int reg)
int base = reg  ~0x3;
int shift = (reg  0x3) * 8;
 
+   /* Prevent SDHCI core from writing reserved bits (e.g. HISPD). */
+   if (reg == SDHCI_HOST_CONTROL)
+   val = ~ESDHC_HOST_CONTROL_RES;
+
clrsetbits_be32(host-ioaddr + base , 0xff  shift, val  shift);
 }
 
-- 
1.6.3.3

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


[PATCH 3/7] sdhci-of: Fix high-speed cards recognition

2009-08-07 Thread Anton Vorontsov
eSDHC fails to recognize some SDHS cards, throwing timeout errors:

  mmc0: error -110 whilst initialising SD card

That's because we calculate timeout value in a wrong way: on eSDHC
hosts the timeout clock is derivied from the SD clock, which is set
dynamically.

As David Vrabel suggested, deriving timeout clock from SD clock is
a common scheme, so let's implement DATA_TIMEOUT_USES_SDCLK quirk
and use it for eSDHC hosts.

Also, from now on we don't need esdhc_get_timeout_clock() callback,
so remove it.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |9 +
 drivers/mmc/host/sdhci.c|9 +++--
 drivers/mmc/host/sdhci.h|2 ++
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 8440fd9..004f24d 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -172,19 +172,13 @@ static unsigned int esdhc_get_min_clock(struct sdhci_host 
*host)
return of_host-clock / 256 / 16;
 }
 
-static unsigned int esdhc_get_timeout_clock(struct sdhci_host *host)
-{
-   struct sdhci_of_host *of_host = sdhci_priv(host);
-
-   return of_host-clock / 1000;
-}
-
 static struct sdhci_of_data sdhci_esdhc = {
.quirks = SDHCI_QUIRK_FORCE_BLK_SZ_2048 |
  SDHCI_QUIRK_BROKEN_CARD_DETECTION |
  SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
  SDHCI_QUIRK_NO_BUSY_IRQ |
  SDHCI_QUIRK_NONSTANDARD_CLOCK |
+ SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
  SDHCI_QUIRK_PIO_NEEDS_DELAY |
  SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET |
  SDHCI_QUIRK_NO_CARD_NO_RESET,
@@ -199,7 +193,6 @@ static struct sdhci_of_data sdhci_esdhc = {
.enable_dma = esdhc_enable_dma,
.get_max_clock = esdhc_get_max_clock,
.get_min_clock = esdhc_get_min_clock,
-   .get_timeout_clock = esdhc_get_timeout_clock,
},
 };
 
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index fc96f8c..288e40b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -591,6 +591,9 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host, 
struct mmc_data *data)
target_timeout = data-timeout_ns / 1000 +
data-timeout_clks / host-clock;
 
+   if (host-quirks  SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)
+   host-timeout_clk = host-clock / 1000;
+
/*
 * Figure out needed cycles.
 * We do this in steps in order to fit inside a 32 bit int.
@@ -1757,13 +1760,15 @@ int sdhci_add_host(struct sdhci_host *host)
host-timeout_clk =
(caps  SDHCI_TIMEOUT_CLK_MASK)  SDHCI_TIMEOUT_CLK_SHIFT;
if (host-timeout_clk == 0) {
-   if (!host-ops-get_timeout_clock) {
+   if (host-ops-get_timeout_clock) {
+   host-timeout_clk = host-ops-get_timeout_clock(host);
+   } else if (!(host-quirks 
+   SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)) {
printk(KERN_ERR
   %s: Hardware doesn't specify timeout clock 
   frequency.\n, mmc_hostname(mmc));
return -ENODEV;
}
-   host-timeout_clk = host-ops-get_timeout_clock(host);
}
if (caps  SDHCI_TIMEOUT_CLK_UNIT)
host-timeout_clk *= 1000;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index c77e9ff..afda7f1 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -232,6 +232,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_FORCE_1_BIT_DATA   (122)
 /* Controller needs 10ms delay between applying power and clock */
 #define SDHCI_QUIRK_DELAY_AFTER_POWER  (123)
+/* Controller uses SDCLK instead of TMCLK for data timeouts */
+#define SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK(124)
 
int irq;/* Device IRQ */
void __iomem *  ioaddr; /* Mapped address */
-- 
1.6.3.3

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


[PATCH 4/7] powerpc: Introduce and document sdhci,wp-inverted property for eSDHC

2009-08-07 Thread Anton Vorontsov
eSDHC block in MPC837x SOCs reports inverted write-protect state,
soon sdhci-of driver will look for sdhci,wp-inverted properties to
decide whether apply a specific quirk.

So, document the property and add it to device tree source files.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 Documentation/powerpc/dts-bindings/fsl/esdhc.txt |2 ++
 arch/powerpc/boot/dts/mpc8377_mds.dts|1 +
 arch/powerpc/boot/dts/mpc8377_rdb.dts|1 +
 arch/powerpc/boot/dts/mpc8377_wlan.dts   |1 +
 arch/powerpc/boot/dts/mpc8378_mds.dts|1 +
 arch/powerpc/boot/dts/mpc8378_rdb.dts|1 +
 arch/powerpc/boot/dts/mpc8379_mds.dts|1 +
 arch/powerpc/boot/dts/mpc8379_rdb.dts|1 +
 8 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt 
b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
index 3ed3797..8a00407 100644
--- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt
@@ -10,6 +10,8 @@ Required properties:
   - interrupts : should contain eSDHC interrupt.
   - interrupt-parent : interrupt source phandle.
   - clock-frequency : specifies eSDHC base clock frequency.
+  - sdhci,wp-inverted : (optional) specifies that eSDHC controller
+reports inverted write-protect state;
   - sdhci,1-bit-only : (optional) specifies that a controller can
 only handle 1-bit data transfers.
 
diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts 
b/arch/powerpc/boot/dts/mpc8377_mds.dts
index f32c281..855782c 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -159,6 +159,7 @@
reg = 0x2e000 0x1000;
interrupts = 42 0x8;
interrupt-parent = ipic;
+   sdhci,wp-inverted;
/* Filled in by U-Boot */
clock-frequency = 0;
};
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts 
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 28e022a..9e2264b 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -173,6 +173,7 @@
reg = 0x2e000 0x1000;
interrupts = 42 0x8;
interrupt-parent = ipic;
+   sdhci,wp-inverted;
/* Filled in by U-Boot */
clock-frequency = 1;
};
diff --git a/arch/powerpc/boot/dts/mpc8377_wlan.dts 
b/arch/powerpc/boot/dts/mpc8377_wlan.dts
index 3febc4e..9a60369 100644
--- a/arch/powerpc/boot/dts/mpc8377_wlan.dts
+++ b/arch/powerpc/boot/dts/mpc8377_wlan.dts
@@ -150,6 +150,7 @@
reg = 0x2e000 0x1000;
interrupts = 42 0x8;
interrupt-parent = ipic;
+   sdhci,wp-inverted;
clock-frequency = 1;
};
};
diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts 
b/arch/powerpc/boot/dts/mpc8378_mds.dts
index f720ab9..f70cf60 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
@@ -159,6 +159,7 @@
reg = 0x2e000 0x1000;
interrupts = 42 0x8;
interrupt-parent = ipic;
+   sdhci,wp-inverted;
/* Filled in by U-Boot */
clock-frequency = 0;
};
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts 
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index a11ead8..4e6a1a4 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -173,6 +173,7 @@
reg = 0x2e000 0x1000;
interrupts = 42 0x8;
interrupt-parent = ipic;
+   sdhci,wp-inverted;
/* Filled in by U-Boot */
clock-frequency = 1;
};
diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts 
b/arch/powerpc/boot/dts/mpc8379_mds.dts
index 4fa221f..645ec51 100644
--- a/arch/powerpc/boot/dts/mpc8379_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8379_mds.dts
@@ -157,6 +157,7 @@
reg = 0x2e000 0x1000;
interrupts = 42 0x8;
interrupt-parent = ipic;
+   sdhci,wp-inverted;
/* Filled in by U-Boot */
clock-frequency = 0;
};
diff --git 

[PATCH 5/7] sdhci-of: Don't hard-code inverted write-protect quirk

2009-08-07 Thread Anton Vorontsov
MPC85xx SOCs have normal write-protect state reporting, so we shouldn't
hard-code the quirk.

Instead, look for sdhci,wp-inverted property, plus check for
mpc837x_{rdb,mds} machines since older device trees don't specify the
new property.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |   14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 004f24d..87aaf4b 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -21,6 +21,7 @@
 #include linux/of.h
 #include linux/of_platform.h
 #include linux/mmc/host.h
+#include asm/machdep.h
 #include sdhci.h
 
 struct sdhci_of_data {
@@ -175,7 +176,6 @@ static unsigned int esdhc_get_min_clock(struct sdhci_host 
*host)
 static struct sdhci_of_data sdhci_esdhc = {
.quirks = SDHCI_QUIRK_FORCE_BLK_SZ_2048 |
  SDHCI_QUIRK_BROKEN_CARD_DETECTION |
- SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
  SDHCI_QUIRK_NO_BUSY_IRQ |
  SDHCI_QUIRK_NONSTANDARD_CLOCK |
  SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
@@ -219,6 +219,15 @@ static int sdhci_of_resume(struct of_device *ofdev)
 
 #endif
 
+static bool __devinit sdhci_of_wp_inverted(struct device_node *np)
+{
+   if (of_get_property(np, sdhci,wp-inverted, NULL))
+   return true;
+
+   /* Old device trees don't have the wp-inverted property. */
+   return machine_is(mpc837x_rdb) || machine_is(mpc837x_mds);
+}
+
 static int __devinit sdhci_of_probe(struct of_device *ofdev,
 const struct of_device_id *match)
 {
@@ -261,6 +270,9 @@ static int __devinit sdhci_of_probe(struct of_device *ofdev,
if (of_get_property(np, sdhci,1-bit-only, NULL))
host-quirks |= SDHCI_QUIRK_FORCE_1_BIT_DATA;
 
+   if (sdhci_of_wp_inverted(np))
+   host-quirks |= SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
+
clk = of_get_property(np, clock-frequency, size);
if (clk  size == sizeof(*clk)  *clk)
of_host-clock = *clk;
-- 
1.6.3.3

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


[PATCH 6/7] sdhci-of: Cleanup eSDHC's set_clock() a little bit

2009-08-07 Thread Anton Vorontsov
- Get rid of incomprehensible if { for { if } } construction for the
  exponential divisor calculation. The first if statement isn't correct
  at all, since it should check for host-max_clk / pre_div / 16 
  clock. The error doesn't cause any bugs because the check in the for
  loop does the right thing, and so the outer check becomes useless;

- For the linear divisor do the same: a single while statement is more
  readable than for + if construction;

- Add dev_dbg() that prints desired and actual clock frequency.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 drivers/mmc/host/sdhci-of.c |   19 ---
 1 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 87aaf4b..048bc01 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -121,8 +121,8 @@ static void esdhc_writeb(struct sdhci_host *host, u8 val, 
int reg)
 
 static void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
 {
-   int div;
int pre_div = 2;
+   int div = 1;
 
clrbits32(host-ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
  ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK);
@@ -130,17 +130,14 @@ static void esdhc_set_clock(struct sdhci_host *host, 
unsigned int clock)
if (clock == 0)
goto out;
 
-   if (host-max_clk / 16  clock) {
-   for (; pre_div  256; pre_div *= 2) {
-   if (host-max_clk / pre_div  clock * 16)
-   break;
-   }
-   }
+   while (host-max_clk / pre_div / 16  clock  pre_div  256)
+   pre_div *= 2;
 
-   for (div = 1; div = 16; div++) {
-   if (host-max_clk / (div * pre_div) = clock)
-   break;
-   }
+   while (host-max_clk / pre_div / div  clock  div  16)
+   div++;
+
+   dev_dbg(mmc_dev(host-mmc), desired SD clock: %d, actual: %d\n,
+   clock, host-max_clk / pre_div / div);
 
pre_div = 1;
div--;
-- 
1.6.3.3

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


[PATCH 7/7] powerpc/85xx: Add eSDHC support for MPC8536DS boards

2009-08-07 Thread Anton Vorontsov
This patch simply adds sdhci node to the device tree.

We specify clock-frequency manually, so that eSDHC will work without
upgrading U-Boot. Though, that'll only work for default setup (1500
MHz) on new board revisions. For non-default setups, it's recommended
to upgrade U-Boot, since it will fixup clock-frequency automatically.

Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
 arch/powerpc/boot/dts/mpc8536ds.dts |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts 
b/arch/powerpc/boot/dts/mpc8536ds.dts
index 22caf69..815cebb 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -250,6 +250,14 @@
phy_type = ulpi;
};
 
+   sd...@2e000 {
+   compatible = fsl,mpc8536-esdhc, fsl,esdhc;
+   reg = 0x2e000 0x1000;
+   interrupts = 72 0x2;
+   interrupt-parent = mpic;
+   clock-frequency = 25000;
+   };
+
serial0: ser...@4500 {
cell-index = 0;
device_type = serial;
-- 
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/4] sdhci-of: Fix high-speed cards recognition

2009-08-07 Thread David Vrabel
Anton Vorontsov wrote:
 eSDHC fails to recognize some SDHS cards, throwing timeout errors:
 
   mmc0: error -110 whilst initialising SD card
 
 That's because we calculate timeout value in a wrong way: on eSDHC
 hosts the timeout clock is derivied from the SD clock, which is set
 dynamically.

I've seen an reference design for an SDHC controller do this also.

 +/* Controller has dynamic timeout clock management */
 +#define SDHCI_QUIRK_DYNAMIC_TIMEOUT_CLOCK(124)

This comment and define would be better if it matched terms used in the
spec.  Suggest:

/* Controller uses SDCLK instead of TMCLK for data timeouts. */
#define SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK  (1  24)

David
-- 
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/


'member of the CSR plc group of companies. CSR plc registered in England and 
Wales, registered number 4187346, registered office Churchill House, Cambridge 
Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom'
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: sequoia: The final kernel image would overwrite the device tree

2009-08-07 Thread Benjamin Herrenschmidt
On Fri, 2009-08-07 at 17:48 +0200, Geert Uytterhoeven wrote:
 | Allocating 0x85e784 bytes for kernel ...
 | platform_ops.vmlinux_alloc = 0x
 | _end = 0x792000
 | The final kernel image would overwrite the device tree?
 
 and it reboots.
 
 However, nm says _end = c085f000.
 
 So in both cases _end is not correct in
 arch/powerpc/boot/main.c:prep_kernel()?
 But depending on CONFIG_PROVE_LOCKING, the test for
 ((unsigned long)_end  ei.memsize) gives different results, and the
 kernel
 boots or doesn't boot?
 
Well, Allocating 0x85e784 looks right...

My experience, however, with a Canyonlands board, is that uBoot has
a bug that makes it always allocate the device-tree below 8M and clash
with the kernel when it gets too big.

I think Stefan fixed that recently, you may need to rebuild your uboot,
I'll let him tell you the details about the fix.

Cheers,
Ben.

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


[PATCH 1/3] crypto: talitos - simplify hmac data size calculation

2009-08-07 Thread Kim Phillips
don't do request-src vs. assoc pointer math - it's the same as adding
assoclen and ivsize (just with more effort).

Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
 drivers/crypto/talitos.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c70775f..b1a651c 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -970,7 +970,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct 
aead_request *areq,
struct talitos_desc *desc = edesc-desc;
unsigned int cryptlen = areq-cryptlen;
unsigned int authsize = ctx-authsize;
-   unsigned int ivsize;
+   unsigned int ivsize = crypto_aead_ivsize(aead);
int sg_count, ret;
int sg_link_tbl_len;
 
@@ -978,11 +978,9 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct 
aead_request *areq,
map_single_talitos_ptr(dev, desc-ptr[0], ctx-authkeylen, ctx-key,
   0, DMA_TO_DEVICE);
/* hmac data */
-   map_single_talitos_ptr(dev, desc-ptr[1], sg_virt(areq-src) -
-  sg_virt(areq-assoc), sg_virt(areq-assoc), 0,
-  DMA_TO_DEVICE);
+   map_single_talitos_ptr(dev, desc-ptr[1], areq-assoclen + ivsize,
+  sg_virt(areq-assoc), 0, DMA_TO_DEVICE);
/* cipher iv */
-   ivsize = crypto_aead_ivsize(aead);
map_single_talitos_ptr(dev, desc-ptr[2], ivsize, giv ?: areq-iv, 0,
   DMA_TO_DEVICE);
 
-- 
1.6.3

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


[PATCH 2/3] crypto: talitos - align locks on cache lines

2009-08-07 Thread Kim Phillips
align channel access locks onto separate cache lines (for performance
reasons).  This is done by placing per-channel variables into their own
private struct, and using the cacheline_aligned attribute within that
struct.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
 drivers/crypto/talitos.c |  141 +++---
 1 files changed, 58 insertions(+), 83 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index b1a651c..5013a2d 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -86,6 +86,25 @@ struct talitos_request {
void *context;
 };
 
+/* per-channel fifo management */
+struct talitos_channel {
+   /* request fifo */
+   struct talitos_request *fifo;
+
+   /* number of requests pending in channel h/w fifo */
+   atomic_t submit_count cacheline_aligned;
+
+   /* request submission (head) lock */
+   spinlock_t head_lock cacheline_aligned;
+   /* index to next free descriptor request */
+   int head;
+
+   /* request release (tail) lock */
+   spinlock_t tail_lock cacheline_aligned;
+   /* index to next in-progress/done descriptor request */
+   int tail;
+};
+
 struct talitos_private {
struct device *dev;
struct of_device *ofdev;
@@ -101,15 +120,6 @@ struct talitos_private {
/* SEC Compatibility info */
unsigned long features;
 
-   /* next channel to be assigned next incoming descriptor */
-   atomic_t last_chan;
-
-   /* per-channel number of requests pending in channel h/w fifo */
-   atomic_t *submit_count;
-
-   /* per-channel request fifo */
-   struct talitos_request **fifo;
-
/*
 * length of the request fifo
 * fifo_len is chfifo_len rounded up to next power of 2
@@ -117,15 +127,10 @@ struct talitos_private {
 */
unsigned int fifo_len;
 
-   /* per-channel index to next free descriptor request */
-   int *head;
-
-   /* per-channel index to next in-progress/done descriptor request */
-   int *tail;
+   struct talitos_channel *chan;
 
-   /* per-channel request submission (head) and release (tail) locks */
-   spinlock_t *head_lock;
-   spinlock_t *tail_lock;
+   /* next channel to be assigned next incoming descriptor */
+   atomic_t last_chan cacheline_aligned;
 
/* request callback tasklet */
struct tasklet_struct done_task;
@@ -282,16 +287,16 @@ static int talitos_submit(struct device *dev, struct 
talitos_desc *desc,
/* emulate SEC's round-robin channel fifo polling scheme */
ch = atomic_inc_return(priv-last_chan)  (priv-num_channels - 1);
 
-   spin_lock_irqsave(priv-head_lock[ch], flags);
+   spin_lock_irqsave(priv-chan[ch].head_lock, flags);
 
-   if (!atomic_inc_not_zero(priv-submit_count[ch])) {
+   if (!atomic_inc_not_zero(priv-chan[ch].submit_count)) {
/* h/w fifo is full */
-   spin_unlock_irqrestore(priv-head_lock[ch], flags);
+   spin_unlock_irqrestore(priv-chan[ch].head_lock, flags);
return -EAGAIN;
}
 
-   head = priv-head[ch];
-   request = priv-fifo[ch][head];
+   head = priv-chan[ch].head;
+   request = priv-chan[ch].fifo[head];
 
/* map descriptor and save caller data */
request-dma_desc = dma_map_single(dev, desc, sizeof(*desc),
@@ -300,7 +305,7 @@ static int talitos_submit(struct device *dev, struct 
talitos_desc *desc,
request-context = context;
 
/* increment fifo head */
-   priv-head[ch] = (priv-head[ch] + 1)  (priv-fifo_len - 1);
+   priv-chan[ch].head = (priv-chan[ch].head + 1)  (priv-fifo_len - 1);
 
smp_wmb();
request-desc = desc;
@@ -309,7 +314,7 @@ static int talitos_submit(struct device *dev, struct 
talitos_desc *desc,
wmb();
out_be32(priv-reg + TALITOS_FF_LO(ch), request-dma_desc);
 
-   spin_unlock_irqrestore(priv-head_lock[ch], flags);
+   spin_unlock_irqrestore(priv-chan[ch].head_lock, flags);
 
return -EINPROGRESS;
 }
@@ -324,11 +329,11 @@ static void flush_channel(struct device *dev, int ch, int 
error, int reset_ch)
unsigned long flags;
int tail, status;
 
-   spin_lock_irqsave(priv-tail_lock[ch], flags);
+   spin_lock_irqsave(priv-chan[ch].tail_lock, flags);
 
-   tail = priv-tail[ch];
-   while (priv-fifo[ch][tail].desc) {
-   request = priv-fifo[ch][tail];
+   tail = priv-chan[ch].tail;
+   while (priv-chan[ch].fifo[tail].desc) {
+   request = priv-chan[ch].fifo[tail];
 
/* descriptors with their done bits set don't get the error */
rmb();
@@ -354,22 +359,22 @@ static void flush_channel(struct device *dev, int ch, int 
error, int reset_ch)
request-desc = NULL;
 
/* increment fifo tail */
-   priv-tail[ch] = 

[PATCH 3/3] crypto: talitos - add support for 36 bit addressing

2009-08-07 Thread Kim Phillips
Enabling extended addressing in the h/w requires we always assign the
extended address component (eptr) of the talitos h/w pointer.  This is
for e500 based platforms with large memories.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
 drivers/crypto/talitos.c |   69 ++---
 drivers/crypto/talitos.h |1 +
 2 files changed, 41 insertions(+), 29 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 5013a2d..c47ffe8 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -146,6 +146,12 @@ struct talitos_private {
 #define TALITOS_FTR_SRC_LINK_TBL_LEN_INCLUDES_EXTENT 0x0001
 #define TALITOS_FTR_HW_AUTH_CHECK 0x0002
 
+static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t 
dma_addr)
+{
+   talitos_ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
+   talitos_ptr-eptr = cpu_to_be32(upper_32_bits(dma_addr));
+}
+
 /*
  * map virtual single (contiguous) pointer to h/w descriptor pointer
  */
@@ -155,8 +161,10 @@ static void map_single_talitos_ptr(struct device *dev,
   unsigned char extent,
   enum dma_data_direction dir)
 {
+   dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
+
talitos_ptr-len = cpu_to_be16(len);
-   talitos_ptr-ptr = cpu_to_be32(dma_map_single(dev, data, len, dir));
+   to_talitos_ptr(talitos_ptr, dma_addr);
talitos_ptr-j_extent = extent;
 }
 
@@ -187,9 +195,9 @@ static int reset_channel(struct device *dev, int ch)
return -EIO;
}
 
-   /* set done writeback and IRQ */
-   setbits32(priv-reg + TALITOS_CCCR_LO(ch), TALITOS_CCCR_LO_CDWE |
- TALITOS_CCCR_LO_CDIE);
+   /* set 36-bit addressing, done writeback enable and done IRQ enable */
+   setbits32(priv-reg + TALITOS_CCCR_LO(ch), TALITOS_CCCR_LO_EAE |
+ TALITOS_CCCR_LO_CDWE | TALITOS_CCCR_LO_CDIE);
 
/* and ICCR writeback, if available */
if (priv-features  TALITOS_FTR_HW_AUTH_CHECK)
@@ -312,7 +320,10 @@ static int talitos_submit(struct device *dev, struct 
talitos_desc *desc,
 
/* GO! */
wmb();
-   out_be32(priv-reg + TALITOS_FF_LO(ch), request-dma_desc);
+   out_be32(priv-reg + TALITOS_FF(ch),
+cpu_to_be32(upper_32_bits(request-dma_desc)));
+   out_be32(priv-reg + TALITOS_FF_LO(ch),
+cpu_to_be32(lower_32_bits(request-dma_desc)));
 
spin_unlock_irqrestore(priv-chan[ch].head_lock, flags);
 
@@ -934,7 +945,7 @@ static int sg_to_link_tbl(struct scatterlist *sg, int 
sg_count,
int n_sg = sg_count;
 
while (n_sg--) {
-   link_tbl_ptr-ptr = cpu_to_be32(sg_dma_address(sg));
+   to_talitos_ptr(link_tbl_ptr, sg_dma_address(sg));
link_tbl_ptr-len = cpu_to_be16(sg_dma_len(sg));
link_tbl_ptr-j_extent = 0;
link_tbl_ptr++;
@@ -1009,7 +1020,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct 
aead_request *areq,
  edesc-src_is_chained);
 
if (sg_count == 1) {
-   desc-ptr[4].ptr = cpu_to_be32(sg_dma_address(areq-src));
+   to_talitos_ptr(desc-ptr[4], sg_dma_address(areq-src));
} else {
sg_link_tbl_len = cryptlen;
 
@@ -1020,14 +1031,14 @@ static int ipsec_esp(struct talitos_edesc *edesc, 
struct aead_request *areq,
  edesc-link_tbl[0]);
if (sg_count  1) {
desc-ptr[4].j_extent |= DESC_PTR_LNKTBL_JUMP;
-   desc-ptr[4].ptr = cpu_to_be32(edesc-dma_link_tbl);
+   to_talitos_ptr(desc-ptr[4], edesc-dma_link_tbl);
dma_sync_single_for_device(dev, edesc-dma_link_tbl,
   edesc-dma_len,
   DMA_BIDIRECTIONAL);
} else {
/* Only one segment now, so no link tbl needed */
-   desc-ptr[4].ptr = cpu_to_be32(sg_dma_address(areq-
- src));
+   to_talitos_ptr(desc-ptr[4],
+  sg_dma_address(areq-src));
}
}
 
@@ -1042,14 +1053,14 @@ static int ipsec_esp(struct talitos_edesc *edesc, 
struct aead_request *areq,
  edesc-dst_is_chained);
 
if (sg_count == 1) {
-   desc-ptr[5].ptr = cpu_to_be32(sg_dma_address(areq-dst));
+   to_talitos_ptr(desc-ptr[5], sg_dma_address(areq-dst));
} else {
struct talitos_ptr *link_tbl_ptr =
edesc-link_tbl[edesc-src_nents + 1];
 
-   desc-ptr[5].ptr = cpu_to_be32((struct talitos_ptr *)
-   

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

2009-08-07 Thread Grant Likely
On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sangw.s...@pengutronix.de wrote:
 Use physmap_of to access RAMs as mtd and add documenation for it. This 
 approach
 is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
 extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
 device tree anyhow, extending physmap_of seems to be the cleanest approach.

 Tested with a phyCORE-MPC5121e.

 Signed-off-by: Wolfram Sang w.s...@pengutronix.de

Looks good to me.

Acked-by: Grant Likely grant.lik...@secretlab.ca

 Cc: Vitaly Wool vw...@ru.mvista.com
 Cc: Artem Bityutskiy dedek...@infradead.org
 Cc: David Woodhouse dw...@infradead.org
 Cc: Ken MacLeod k...@bitsko.slc.ut.us
 Cc: Albrecht Dreß albrecht.dr...@arcor.de
 ---
  Documentation/powerpc/dts-bindings/mtd-physmap.txt |   42 ---
  drivers/mtd/maps/physmap_of.c                      |    4 ++
  2 files changed, 30 insertions(+), 16 deletions(-)

 diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt 
 b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
 index 667c9bd..80152cb 100644
 --- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt
 +++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt
 @@ -1,18 +1,19 @@
 -CFI or JEDEC memory-mapped NOR flash
 +CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...)

  Flash chips (Memory Technology Devices) are often used for solid state
  file systems on embedded devices.

 - - compatible : should contain the specific model of flash chip(s)
 -   used, if known, followed by either cfi-flash or jedec-flash
 - - reg : Address range(s) of the flash chip(s)
 + - compatible : should contain the specific model of mtd chip(s)
 +   used, if known, followed by either cfi-flash, jedec-flash
 +   or mtd-ram.
 + - reg : Address range(s) of the mtd chip(s)
    It's possible to (optionally) define multiple reg tuples so that
 -   non-identical NOR chips can be described in one flash node.
 - - bank-width : Width (in bytes) of the flash bank.  Equal to the
 +   non-identical chips can be described in one node.
 + - bank-width : Width (in bytes) of the bank.  Equal to the
    device width times the number of interleaved chips.
 - - device-width : (optional) Width of a single flash chip.  If
 + - device-width : (optional) Width of a single mtd chip.  If
    omitted, assumed to be equal to 'bank-width'.
 - - #address-cells, #size-cells : Must be present if the flash has
 + - #address-cells, #size-cells : Must be present if the device has
    sub-nodes representing partitions (see below).  In this case
    both #address-cells and #size-cells must be equal to 1.

 @@ -22,24 +23,24 @@ are defined:
  - vendor-id : Contains the flash chip's vendor id (1 byte).
  - device-id : Contains the flash chip's device id (1 byte).

 -In addition to the information on the flash bank itself, the
 +In addition to the information on the mtd bank itself, the
  device tree may optionally contain additional information
 -describing partitions of the flash address space.  This can be
 +describing partitions of the address space.  This can be
  used on platforms which have strong conventions about which
 -portions of the flash are used for what purposes, but which don't
 +portions of a flash are used for what purposes, but which don't
  use an on-flash partition table such as RedBoot.

 -Each partition is represented as a sub-node of the flash device.
 +Each partition is represented as a sub-node of the mtd device.
  Each node's name represents the name of the corresponding
 -partition of the flash device.
 +partition of the mtd device.

  Flash partitions
 - - reg : The partition's offset and size within the flash bank.
 - - label : (optional) The label / name for this flash partition.
 + - reg : The partition's offset and size within the mtd bank.
 + - label : (optional) The label / name for this partition.
    If omitted, the label is taken from the node name (excluding
    the unit address).
  - read-only : (optional) This parameter, if present, is a hint to
 -   Linux that this flash partition should only be mounted
 +   Linux that this partition should only be mounted
    read-only.  This is usually used for flash partitions
    containing early-boot firmware images or data which should not
    be clobbered.
 @@ -78,3 +79,12 @@ Here an example with multiple reg tuples:
                        reg = 0 0x0400;
                };
        };
 +
 +An example using SRAM:
 +
 +       s...@2,0 {
 +               compatible = samsung,k6f1616u6a, mtd-ram;
 +               reg = 2 0 0x0020;
 +               bank-width = 2;
 +       };
 +
 diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
 index 39d357b..45eee20 100644
 --- a/drivers/mtd/maps/physmap_of.c
 +++ b/drivers/mtd/maps/physmap_of.c
 @@ -360,6 +360,10 @@ static struct of_device_id of_flash_match[] = {
                .data           = (void *)jedec_probe,
        },
        {
 +               .compatible     = 

Re: [5200] ATA and (BAD) interrupts question

2009-08-07 Thread Grant Likely
On Tue, Jul 28, 2009 at 6:50 AM, Albrecht Dreßalbrecht.dr...@arcor.de wrote:
 Hi all,

 I run linux 2.6.29.1 from kernel.org on a custom Freescale MPC5200B based 
 board, which has a CF card attached to the 5200's ATA.  The CF seems to run 
 nicely, but I am somewhat confused by the interrupts reproted by the kernel.

 Immediately after the boot, /proc/interrupts reports (inter alia)

 135:          8  MPC52xx Peripherals Edge      mpc52xx_ata
 194:          0  MPC52xx SDMA Edge      ATA task
 BAD:         44

 Then I say 'mount -t vfat -o noatime /dev/sda1 /mnt/cf0', and I get

 135:         41  MPC52xx Peripherals Edge      mpc52xx_ata
 194:          0  MPC52xx SDMA Edge      ATA task
 BAD:         44

 Then, I recursively copy a folder to the CF card:

 135:     125111  MPC52xx Peripherals Edge      mpc52xx_ata
 194:          0  MPC52xx SDMA Edge      ATA task
 BAD:     121863

 Is it correct that the ATA task interrupts are still 0, and that I get such 
 a high number of BAD ones?  Is there a way to detect which source actually 
 triggered the BAD interrupts?

No, not really, but I'd spend some time looking at the DMA portion of
the IRQ handler.  Either edge IRQs are not getting acked correctly, or
the interrupt controller driver is not reading the pending IRQs
correctly.

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