Re: [PATCH 0/3] ARM: dts: omap3-igep MMC updates for v3.13

2013-10-19 Thread Javier Martinez Canillas 
[cc'ing current Benoit's address instead of the old one]

On Sat, Oct 19, 2013 at 9:54 PM, Enric Balletbo i Serra
 wrote:
> Hi Benoit,
>
> This series are some updates for IGEP boards that would be great if can make
> it for v3.13 (not sure if merge window is already closed as I saw your last
> pull request).
>
> The first patch is fix for mmc1 that should be configured for 4 bits not 8,
> the second patch add support for the WiFi module connected to MMC2 SDIO
> interface, and the third patch, updates the default processor to AM/DM37x
> as most of the boards uses this processor instead of the old OMAP353x.
>
> Best regards,
>

Hi Enric,

Thanks a lot for this patch-set. I don't have access to my IGEP board
right now so I can't give a try but will do as soon as possible.

I've just two minors nits that I commented on the individual patches
but I'm not sure if those justifies a v2 so:

Reviewed-by: Javier Martinez Canillas 

> Enric Balletbo i Serra (3):
>   ARM: dts: omap3-igep: Fix bus-width for mmc1.
>   ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to
> SDIO.
>   ARM: dts: omap3-igep*: Update to use the TI AM/DM37x processor.
>
>  arch/arm/boot/dts/omap3-igep.dtsi| 55 
> ++--
>  arch/arm/boot/dts/omap3-igep0020.dts |  4 +--
>  arch/arm/boot/dts/omap3-igep0030.dts |  4 +--
>  3 files changed, 51 insertions(+), 12 deletions(-)
>
> --
> 1.8.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.

2013-10-19 Thread Javier Martinez Canillas 
Hi Enric,

On Sat, Oct 19, 2013 at 9:54 PM, Enric Balletbo i Serra
 wrote:
> The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
> both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
> the same MMC interface and uses the same GPIOs.
>
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  arch/arm/boot/dts/omap3-igep.dtsi | 45 
> ++-
>  1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
> b/arch/arm/boot/dts/omap3-igep.dtsi
> index d4fecce..882e318 100644
> --- a/arch/arm/boot/dts/omap3-igep.dtsi
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -24,6 +24,25 @@
> ti,mcbsp = <&mcbsp2>;
> ti,codec = <&twl_audio>;
> };
> +
> +   vdd33: regulator-vdd33 {
> +   compatible = "regulator-fixed";
> +   regulator-name = "vdd33";
> +   regulator-always-on;
> +   };
> +
> +   lbee1usjyc_vmmc: lbee1usjyc_vmmc {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&lbee1usjyc_pins>;
> +   compatible = "regulator-fixed";
> +   regulator-name = "regulator-lbee1usjyc";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   gpio = <&gpio5 10 0>;   /* gpio_138 WIFI_PDN */

Is better if you use GPIO_ACTIVE_HIGH instead of 0 here.

> +   startup-delay-us = <1>;
> +   enable-active-high;
> +   vin-supply = <&vdd33>;
> +   };
>  };
>
>  &omap3_pmx_core {
> @@ -48,6 +67,15 @@
> >;
> };
>
> +   /* WiFi/BT combo */
> +   lbee1usjyc_pins: pinmux_lbee1usjyc_pins {
> +   pinctrl-single,pins = <
> +   0x136 (PIN_OUTPUT | MUX_MODE4)  /* 
> sdmmc2_dat5.gpio_137 */
> +   0x138 (PIN_OUTPUT | MUX_MODE4)  /* 
> sdmmc2_dat6.gpio_138 */
> +   0x13a (PIN_OUTPUT | MUX_MODE4)  /* 
> sdmmc2_dat7.gpio_139 */
> +   >;
> +   };
> +

Is this enough to correctly reset the chip or do you also have a patch
to do the init sequence on pdata-quirks.c?

> mcbsp2_pins: pinmux_mcbsp2_pins {
> pinctrl-single,pins = <
> 0x10c (PIN_INPUT | MUX_MODE0)   /* 
> mcbsp2_fsx.mcbsp2_fsx */
> @@ -68,6 +96,17 @@
> >;
> };
>
> +   mmc2_pins: pinmux_mmc2_pins {
> +   pinctrl-single,pins = <
> +   0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc2_clk.sdmmc2_clk */
> +   0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc2_cmd.sdmmc2_cmd */
> +   0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc2_dat0.sdmmc2_dat0 */
> +   0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc2_dat1.sdmmc2_dat1 */
> +   0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc2_dat2.sdmmc2_dat2 */
> +   0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc2_dat3.sdmmc2_dat3 */
> +   >;
> +   };
> +
> smsc911x_pins: pinmux_smsc911x_pins {
> pinctrl-single,pins = <
> 0x1a2 (PIN_INPUT | MUX_MODE4)   /* 
> mcspi1_cs2.gpio_176 */
> @@ -114,7 +153,11 @@
>  };
>
>  &mmc2 {
> -   status = "disabled";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&mmc2_pins>;
> +   vmmc-supply = <&lbee1usjyc_vmmc>;
> +   bus-width = <4>;
> +   non-removable;
>  };
>
>  &mmc3 {
> --
> 1.8.1.2
>

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ARM: dts: omap3-igep: Fix bus-width for mmc1.

2013-10-19 Thread Javier Martinez Canillas 
Hi Enric,

On Sat, Oct 19, 2013 at 9:54 PM, Enric Balletbo i Serra
 wrote:
> Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
> do not mux data pins from mmc1_data5 to mmc1_data7.
>

I guess you meant pins from mmc1_data4 instead mmc1_data5? (i.e: only
data0 to data3 have to be mux'ed for bus-width = <4>).

> Signed-off-by: Enric Balletbo i Serra 
> ---
>  arch/arm/boot/dts/omap3-igep.dtsi | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
> b/arch/arm/boot/dts/omap3-igep.dtsi
> index ba1e58b..d4fecce 100644
> --- a/arch/arm/boot/dts/omap3-igep.dtsi
> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
> @@ -65,10 +65,6 @@
> 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc1_dat1.sdmmc1_dat1 */
> 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc1_dat2.sdmmc1_dat2 */
> 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/* 
> sdmmc1_dat3.sdmmc1_dat3 */
> -   0x120 (PIN_INPUT | MUX_MODE0)   /* 
> sdmmc1_dat4.sdmmc1_dat4 */
> -   0x122 (PIN_INPUT | MUX_MODE0)   /* 
> sdmmc1_dat5.sdmmc1_dat5 */
> -   0x124 (PIN_INPUT | MUX_MODE0)   /* 
> sdmmc1_dat6.sdmmc1_dat6 */
> -   0x126 (PIN_INPUT | MUX_MODE0)   /* 
> sdmmc1_dat7.sdmmc1_dat7 */
> >;
> };
>
> @@ -114,7 +110,7 @@
>pinctrl-0 = <&mmc1_pins>;
>vmmc-supply = <&vmmc1>;
>vmmc_aux-supply = <&vsim>;
> -  bus-width = <8>;
> +  bus-width = <4>;
>  };
>
>  &mmc2 {
> --
> 1.8.1.2
>

Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: igep0033: Add mmc1 node for SDCARD support.

2013-10-19 Thread Enric Balletbo i Serra 
Add mmc1 dt node to IGEP COM AQUILA board.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/am335x-igep0033.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi 
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 06eba07..6196244 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -44,6 +44,13 @@
regulator-max-microvolt = <500>;
regulator-boot-on;
};
+
+   vmmc: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
 &am33xx_pinmux {
@@ -180,6 +187,12 @@
};
 };
 
+&mmc1 {
+   status = "okay";
+   vmmc-supply = <&vmmc>;
+   bus-width = <4>;
+};
+
 &uart0 {
status = "okay";
pinctrl-names = "default";
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] ARM: dts: omap3-igep*: Update to use the TI AM/DM37x processor.

2013-10-19 Thread Enric Balletbo i Serra 
Most of the boards are using the TI AM/DM37x processor, there is only a small
quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
omap36xx.dtsi include instead of omap34xx.dtsi include.

To avoid confusion we have added to the model the (TI AM/DM37x) comment.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/omap3-igep.dtsi| 4 ++--
 arch/arm/boot/dts/omap3-igep0020.dts | 4 ++--
 arch/arm/boot/dts/omap3-igep0030.dts | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index 882e318..04b83ce 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for IGEP Technology devices
+ * Common device tree for IGEP boards based on AM/DM37x
  *
  * Copyright (C) 2012 Javier Martinez Canillas 
  * Copyright (C) 2012 Enric Balletbo i Serra 
@@ -10,7 +10,7 @@
  */
 /dts-v1/;
 
-#include "omap34xx.dtsi"
+#include "omap36xx.dtsi"
 
 / {
memory {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts 
b/arch/arm/boot/dts/omap3-igep0020.dts
index 750ce84..495ef0c 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for IGEPv2 board
+ * Device Tree Source for IGEPv2 Rev. (TI OMAP AM/DM37x)
  *
  * Copyright (C) 2012 Javier Martinez Canillas 
  * Copyright (C) 2012 Enric Balletbo i Serra 
@@ -12,7 +12,7 @@
 #include "omap3-igep.dtsi"
 
 / {
-   model = "IGEPv2";
+   model = "IGEPv2 (TI OMAP AM/DM37x)";
compatible = "isee,omap3-igep0020", "ti,omap3";
 
leds {
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts 
b/arch/arm/boot/dts/omap3-igep0030.dts
index 525e6d9..02a23f8 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -1,5 +1,5 @@
 /*
- * Device Tree Source for IGEP COM Module
+ * Device Tree Source for IGEP COM MODULE (TI OMAP AM/DM37x)
  *
  * Copyright (C) 2012 Javier Martinez Canillas 
  * Copyright (C) 2012 Enric Balletbo i Serra 
@@ -12,7 +12,7 @@
 #include "omap3-igep.dtsi"
 
 / {
-   model = "IGEP COM Module";
+   model = "IGEP COM MODULE (TI OMAP AM/DM37x)";
compatible = "isee,omap3-igep0030", "ti,omap3";
 
leds {
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] ARM: dts: omap3-igep: Fix bus-width for mmc1.

2013-10-19 Thread Enric Balletbo i Serra 
Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
do not mux data pins from mmc1_data5 to mmc1_data7.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/omap3-igep.dtsi | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index ba1e58b..d4fecce 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -65,10 +65,6 @@
0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_dat1.sdmmc1_dat1 */
0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_dat2.sdmmc1_dat2 */
0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc1_dat3.sdmmc1_dat3 */
-   0x120 (PIN_INPUT | MUX_MODE0)   /* 
sdmmc1_dat4.sdmmc1_dat4 */
-   0x122 (PIN_INPUT | MUX_MODE0)   /* 
sdmmc1_dat5.sdmmc1_dat5 */
-   0x124 (PIN_INPUT | MUX_MODE0)   /* 
sdmmc1_dat6.sdmmc1_dat6 */
-   0x126 (PIN_INPUT | MUX_MODE0)   /* 
sdmmc1_dat7.sdmmc1_dat7 */
>;
};
 
@@ -114,7 +110,7 @@
   pinctrl-0 = <&mmc1_pins>;
   vmmc-supply = <&vmmc1>;
   vmmc_aux-supply = <&vsim>;
-  bus-width = <8>;
+  bus-width = <4>;
 };
 
 &mmc2 {
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] ARM: dts: omap3-igep MMC updates for v3.13

2013-10-19 Thread Enric Balletbo i Serra 
Hi Benoit,

This series are some updates for IGEP boards that would be great if can make
it for v3.13 (not sure if merge window is already closed as I saw your last
pull request).

The first patch is fix for mmc1 that should be configured for 4 bits not 8,
the second patch add support for the WiFi module connected to MMC2 SDIO
interface, and the third patch, updates the default processor to AM/DM37x
as most of the boards uses this processor instead of the old OMAP353x.

Best regards,

Enric Balletbo i Serra (3):
  ARM: dts: omap3-igep: Fix bus-width for mmc1.
  ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to
SDIO.
  ARM: dts: omap3-igep*: Update to use the TI AM/DM37x processor.

 arch/arm/boot/dts/omap3-igep.dtsi| 55 ++--
 arch/arm/boot/dts/omap3-igep0020.dts |  4 +--
 arch/arm/boot/dts/omap3-igep0030.dts |  4 +--
 3 files changed, 51 insertions(+), 12 deletions(-)

-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO.

2013-10-19 Thread Enric Balletbo i Serra 
The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
the same MMC interface and uses the same GPIOs.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/omap3-igep.dtsi | 45 ++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index d4fecce..882e318 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -24,6 +24,25 @@
ti,mcbsp = <&mcbsp2>;
ti,codec = <&twl_audio>;
};
+
+   vdd33: regulator-vdd33 {
+   compatible = "regulator-fixed";
+   regulator-name = "vdd33";
+   regulator-always-on;
+   };
+
+   lbee1usjyc_vmmc: lbee1usjyc_vmmc {
+   pinctrl-names = "default";
+   pinctrl-0 = <&lbee1usjyc_pins>;
+   compatible = "regulator-fixed";
+   regulator-name = "regulator-lbee1usjyc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio5 10 0>;   /* gpio_138 WIFI_PDN */
+   startup-delay-us = <1>;
+   enable-active-high;
+   vin-supply = <&vdd33>;
+   };
 };
 
 &omap3_pmx_core {
@@ -48,6 +67,15 @@
>;
};
 
+   /* WiFi/BT combo */
+   lbee1usjyc_pins: pinmux_lbee1usjyc_pins {
+   pinctrl-single,pins = <
+   0x136 (PIN_OUTPUT | MUX_MODE4)  /* sdmmc2_dat5.gpio_137 
*/
+   0x138 (PIN_OUTPUT | MUX_MODE4)  /* sdmmc2_dat6.gpio_138 
*/
+   0x13a (PIN_OUTPUT | MUX_MODE4)  /* sdmmc2_dat7.gpio_139 
*/
+   >;
+   };
+
mcbsp2_pins: pinmux_mcbsp2_pins {
pinctrl-single,pins = <
0x10c (PIN_INPUT | MUX_MODE0)   /* 
mcbsp2_fsx.mcbsp2_fsx */
@@ -68,6 +96,17 @@
>;
};
 
+   mmc2_pins: pinmux_mmc2_pins {
+   pinctrl-single,pins = <
+   0x128 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_clk.sdmmc2_clk */
+   0x12a (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_cmd.sdmmc2_cmd */
+   0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat0.sdmmc2_dat0 */
+   0x12e (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat1.sdmmc2_dat1 */
+   0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat2.sdmmc2_dat2 */
+   0x132 (PIN_INPUT_PULLUP | MUX_MODE0)/* 
sdmmc2_dat3.sdmmc2_dat3 */
+   >;
+   };
+
smsc911x_pins: pinmux_smsc911x_pins {
pinctrl-single,pins = <
0x1a2 (PIN_INPUT | MUX_MODE4)   /* 
mcspi1_cs2.gpio_176 */
@@ -114,7 +153,11 @@
 };
 
 &mmc2 {
-   status = "disabled";
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc2_pins>;
+   vmmc-supply = <&lbee1usjyc_vmmc>;
+   bus-width = <4>;
+   non-removable;
 };
 
 &mmc3 {
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/1] ARM: OMAP2+: DRA7: hwmod: Add hwmod data for MDIO and CPSW

2013-10-19 Thread Paul Walmsley 
On Fri, 18 Oct 2013, Mugunthan V N wrote:

> Adding hwmod data for CPSW and MDIO which is present in DRA7xx SoC
> 
> Signed-off-by: Mugunthan V N 

Has a DRA7xx public TRM been published yet?


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/11] ARM: OMAP3: CM/PM: add API for forcing IVA2 clk enable/disable

2013-10-19 Thread Paul Walmsley 
On Sat, 19 Oct 2013, Paul Walmsley wrote:

> On Fri, 11 Oct 2013, Tero Kristo wrote:
> 
> > OMAP3 PM code directly writes to CM register space to enable/disable IVA2
> > clock during boot during the IVA2 reset. Direct access shall be avoided,
> > thus implement an API call for this, and change the PM core to use this.
> > 
> > Signed-off-by: Tero Kristo 
> > ---
> >  arch/arm/mach-omap2/cm3xxx.c |   10 ++
> >  arch/arm/mach-omap2/cm3xxx.h |1 +
> >  arch/arm/mach-omap2/pm34xx.c |7 +++
> >  3 files changed, 14 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
> > index f13742b..55bf939 100644
> > --- a/arch/arm/mach-omap2/cm3xxx.c
> > +++ b/arch/arm/mach-omap2/cm3xxx.c
> > @@ -686,6 +686,16 @@ u32 omap3_cm_write_module_clken(s16 module, u8 regs, 
> > bool fck, u32 val)
> > return omap3_cm_access_module_clken(module, regs, fck, val, true);
> >  }
> >  
> > +void omap3_cm_force_iva_clk(bool enable)
> > +{
> > +   u32 val = 0;
> > +
> > +   if (enable)
> > +   val = OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK;
> > +
> > +   omap2_cm_write_mod_reg(val, OMAP3430_IVA2_MOD, CM_FCLKEN);
> > +}
> > +
> 
> Please implement this as a generic clockdomain API that can be called for 
> any clockdomain.

Oops, please ignore this comment for this patch; it was intended to be in 
regards to the CLKSTST-reading patch, & have responded appropriately to 
that patch.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/11] ARM: OMAP3: CM/PM: add new API for checking IVA2 idle status

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> OMAP3 PM code needs this functionality during the IVA2 reset, but is currently
> using direct CM register accesses for this purpose. Implement a new API so
> the PM code can use this instead.
> 
> Signed-off-by: Tero Kristo 
> ---
>  arch/arm/mach-omap2/cm3xxx.c |6 ++
>  arch/arm/mach-omap2/cm3xxx.h |1 +
>  arch/arm/mach-omap2/pm34xx.c |3 +--
>  3 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
> index 55bf939..b0509b9 100644
> --- a/arch/arm/mach-omap2/cm3xxx.c
> +++ b/arch/arm/mach-omap2/cm3xxx.c
> @@ -696,6 +696,12 @@ void omap3_cm_force_iva_clk(bool enable)
>   omap2_cm_write_mod_reg(val, OMAP3430_IVA2_MOD, CM_FCLKEN);
>  }
>  
> +bool omap3_cm_is_iva_active(void)
> +{
> + return omap2_cm_read_mod_reg(OMAP3430_IVA2_MOD, OMAP3430_CM_CLKSTST) &
> + OMAP3430_CLKACTIVITY_IVA2_MASK;
> +}
> +

Please implement this as a generic clockdomain API that can be called for 
any clockdomain.



- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/11] ARM: OMAP3: CM/PM: add API for accessing module clock enable registers

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> PRCM chain handler needs these to properly acknowledge wakeup events.
> Currently this functionality is implemented as direct register accesses,
> but as the CM code should eventually move to its own driver, separate
> API calls are now added for this purpose. PM core code is also changed
> to use these APIs.
> 
> Signed-off-by: Tero Kristo 

In theory, shouldn't the clock code know which clocks are enabled and 
disabled?  Seems like if it can use standard CCF code for this, this code 
might also be able to avoid slow PRM/CM register accesses.  
That prcm_clear_mod_irqs() function should probably be a hwmod-based 
interface anyway...


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/11] ARM: OMAP2+: CM: move direct register write macros to internal header

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> The direct register access macros should not be exposed to CM clients.
> Thus, move the register macros to their own file and only include these
> to the cm_*.c files.
> 
> Signed-off-by: Tero Kristo 

The basic idea here looks great, obviously we can't merge it yet...

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/11] ARM: OMAP3: PRM: move iva2 force idle functionality to PRM driver

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> This is correct location for this instead of the PM core, as it is accessing
> PRM registers directly.
> 
> Signed-off-by: Tero Kristo 

This is custom reset code for the IVA2, not specifically PRM code, so it 
should go into a separate arch/arm/mach-omap2/iva2.c file, before it gets 
moved out into drivers/.  (Similar to what's been done for 
mach-omap2/i2c.c and mach-omap2/hdq1w.c, etc.)  Unfortunately, this is 
going to require separate interfaces for all of those direct PRM register 
accesses as well.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/11] ARM: OMAP3: CM/PM: add API for forcing IVA2 clk enable/disable

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> OMAP3 PM code directly writes to CM register space to enable/disable IVA2
> clock during boot during the IVA2 reset. Direct access shall be avoided,
> thus implement an API call for this, and change the PM core to use this.
> 
> Signed-off-by: Tero Kristo 
> ---
>  arch/arm/mach-omap2/cm3xxx.c |   10 ++
>  arch/arm/mach-omap2/cm3xxx.h |1 +
>  arch/arm/mach-omap2/pm34xx.c |7 +++
>  3 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/cm3xxx.c b/arch/arm/mach-omap2/cm3xxx.c
> index f13742b..55bf939 100644
> --- a/arch/arm/mach-omap2/cm3xxx.c
> +++ b/arch/arm/mach-omap2/cm3xxx.c
> @@ -686,6 +686,16 @@ u32 omap3_cm_write_module_clken(s16 module, u8 regs, 
> bool fck, u32 val)
>   return omap3_cm_access_module_clken(module, regs, fck, val, true);
>  }
>  
> +void omap3_cm_force_iva_clk(bool enable)
> +{
> + u32 val = 0;
> +
> + if (enable)
> + val = OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK;
> +
> + omap2_cm_write_mod_reg(val, OMAP3430_IVA2_MOD, CM_FCLKEN);
> +}
> +

Please implement this as a generic clockdomain API that can be called for 
any clockdomain.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/11] ARM: OMAP3: CM/PM: add API for forcing IVA2 clk enable/disable

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> OMAP3 PM code directly writes to CM register space to enable/disable IVA2
> clock during boot during the IVA2 reset. Direct access shall be avoided,
> thus implement an API call for this, and change the PM core to use this.
> 
> Signed-off-by: Tero Kristo 

Seems like this type of clock forcing needs to be coordinated with the 
clock framework.  Could you please work with Mike to get a decent 
interface implemented for this?


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/11] ARM: OMAP3: control: add API for setting IVA bootmode

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> OMAP3 PM core requires IVA2 bootmode to be set to idle during init. Currently,
> a direct register write is used for this. Add a new ctrl API for this purpose
> instead.
> 
> Signed-off-by: Tero Kristo 

Thanks, queued.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/11] ARM: OMAP3: CM/control: move CM scratchpad save to CM driver

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> OMAP3 PM code for off-mode currently saves the scratchpad contents for CM
> registers within OMAP control module driver. However, as we are separating
> CM code into its own driver, this must be moved also. This patch adds a
> new API for saving the CM scratchpad contents and uses this from the high
> level scratchpad save function.
> 
> Signed-off-by: Tero Kristo 

Thanks, queued.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/11] ARM: OMAP3: clock: add API to enable/disable autoidle for a single clock

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> Some drivers require direct access to the autoidle functionality of the
> interface clocks. Added clock APIs for these, so that the drivers do not
> need to access CM registers directly.
> 
> Signed-off-by: Tero Kristo 

Thanks, queued.  Please coordinate with Mike to get 
allow_idle/deny_idle-type interfaces into the Common Clock Framework, so 
these can be replaced with standard CCF-type allow_idle() & deny_idle() 
functions.  That interface should include use-counting so multiple callers 
can use allow_idle() and deny_idle() without stomping on each other.


- Paul

> ---
>  arch/arm/mach-omap2/clock.c |   38 ++
>  arch/arm/mach-omap2/clock.h |2 ++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 0c38ca9..c7c5d31 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -543,6 +543,44 @@ int omap2_clk_disable_autoidle_all(void)
>  }
>  
>  /**
> + * omap2_clk_deny_idle - disable autoidle on an OMAP clock
> + * @clk: struct clk * to disable autoidle for
> + *
> + * Disable autoidle on an OMAP clock.
> + */
> +int omap2_clk_deny_idle(struct clk *clk)
> +{
> + struct clk_hw_omap *c;
> +
> + if (__clk_get_flags(clk) & CLK_IS_BASIC)
> + return -EINVAL;
> +
> + c = to_clk_hw_omap(__clk_get_hw(clk));
> + if (c->ops && c->ops->deny_idle)
> + c->ops->deny_idle(c);
> + return 0;
> +}
> +
> +/**
> + * omap2_clk_allow_idle - enable autoidle on an OMAP clock
> + * @clk: struct clk * to enable autoidle for
> + *
> + * Enable autoidle on an OMAP clock.
> + */
> +int omap2_clk_allow_idle(struct clk *clk)
> +{
> + struct clk_hw_omap *c;
> +
> + if (__clk_get_flags(clk) & CLK_IS_BASIC)
> + return -EINVAL;
> +
> + c = to_clk_hw_omap(__clk_get_hw(clk));
> + if (c->ops && c->ops->allow_idle)
> + c->ops->allow_idle(c);
> + return 0;
> +}
> +
> +/**
>   * omap2_clk_enable_init_clocks - prepare & enable a list of clocks
>   * @clk_names: ptr to an array of strings of clock names to enable
>   * @num_clocks: number of clock names in @clk_names
> diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
> index 7aa32cd..82916cc 100644
> --- a/arch/arm/mach-omap2/clock.h
> +++ b/arch/arm/mach-omap2/clock.h
> @@ -411,6 +411,8 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
>  void omap2_init_clk_hw_omap_clocks(struct clk *clk);
>  int omap2_clk_enable_autoidle_all(void);
>  int omap2_clk_disable_autoidle_all(void);
> +int omap2_clk_allow_idle(struct clk *clk);
> +int omap2_clk_deny_idle(struct clk *clk);
>  void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
>  int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
>  void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
> -- 
> 1.7.9.5
> 


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/11] ARM: OMAP3: McBSP: do not access CM register directly

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> McBSP driver require special hacks to enable/disable the autoidle feature
> for its interface clock for the proper function of the sidetone hardware.
> Currently the driver just writes CM registers directly, which should be
> avoided. Thus, changed the driver to use the new deny/allow_autoidle
> clock API calls.
> 
> Signed-off-by: Tero Kristo 
> Cc: Peter Ujfalusi 

Thanks, queued.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/11] ARM: OMAP2: CM/PM: remove direct register accesses outside CM code

2013-10-19 Thread Paul Walmsley 
On Fri, 11 Oct 2013, Tero Kristo wrote:

> Users of the CM funtionality should not access the CM registers directly
> by themselves. Thus, added new CM driver APIs for the OMAP2 specific
> functionalities which support the existing direct register accesses, and
> changed the platform code to use these. This is done in preparation
> for moving the CM code into its own individual driver.
> 
> Signed-off-by: Tero Kristo 

Thanks, queued.  Not thrilled about returning register bitfields directly 
from these CM functions, but it's incrementally better than what's there.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] ARM: OMAP2+: CM/SCM: clean up direct register accesses

2013-10-19 Thread Paul Walmsley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tony,

The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:

  Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/for-v3.13/cm-scm-cleanup-a

for you to fetch changes up to 49e03402327ab69a26f604398982ef14123900a2:

  ARM: OMAP3: control: add API for setting IVA bootmode (2013-10-19 10:11:52 
-0600)

- 
Move some of the OMAP2+ CM and System Control Module direct
register accesses into CM- and System Control
Module-specific "drivers" underneath arch/arm/mach-omap2/.  This
is a prerequisite for moving this code out of arch/arm/mach-omap2/ into
drivers/.

Basic test logs are available here:

http://www.pwsan.com/omap/testlogs/cm_scm_cleanup_a_v3.13/20131019101809/

- 
Tero Kristo (5):
  ARM: OMAP2: CM/PM: remove direct register accesses outside CM code
  ARM: OMAP3: clock: add API to enable/disable autoidle for a single clock
  ARM: OMAP3: McBSP: do not access CM register directly
  ARM: OMAP3: CM/control: move CM scratchpad save to CM driver
  ARM: OMAP3: control: add API for setting IVA bootmode

 arch/arm/mach-omap2/clkt2xxx_apll.c  |  4 +-
 arch/arm/mach-omap2/clkt2xxx_dpllcore.c  | 11 ++---
 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 24 +++---
 arch/arm/mach-omap2/clock.c  | 38 
 arch/arm/mach-omap2/clock.h  |  2 +
 arch/arm/mach-omap2/cm2xxx.c | 67 
 arch/arm/mach-omap2/cm2xxx.h |  8 
 arch/arm/mach-omap2/cm3xxx.c | 22 +
 arch/arm/mach-omap2/cm3xxx.h |  1 +
 arch/arm/mach-omap2/control.c| 54 +++---
 arch/arm/mach-omap2/control.h|  1 +
 arch/arm/mach-omap2/mcbsp.c  | 16 +++
 arch/arm/mach-omap2/pm24xx.c | 24 +-
 arch/arm/mach-omap2/pm34xx.c |  3 +-
 14 files changed, 177 insertions(+), 98 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJSYrwzAAoJEMePsQ0LvSpLAZoP/AkIs74RMF42SmWCfmhPHyz9
PiUI6AFchOHLoRPf06vZcVylFPH3Tyb6GvNrB+tlmdJ8K7hsJjHJW4JMsnL6jZlN
53Yhe9Ij/7Ydnat8D21dVFj+NX7Sks/qoqwMPDIa9BcLTvGZ9ruOpAWZQcK8qdRz
BaWM8uQeQXt0/Asgy+qJW2Rn9YwyGLaDQBOduSsidC6Jl5mk4rrRr1wBHkmjAfvn
g41/7ehbzt6BUFMn0hWy2x47bWv+LH5oJlrKr8X7Ocu7bgZC8H6dcAgMho6fdTe8
fIJAuCHs7X+tAYXtVoMBzm3bRIrr59x25PULVzzEkzj1B8q7e0y6AdB87aPIo4Yg
ebREEq5S+iWdniWvGNCqK5pKXeeAIPjWLVaGbDsFx1POq5JsvBNtlt1zCCGU73/S
wK9J15POnrHjeyDQZha2w+sdAxT8kj/EbTXakehPLkX1hW/vc7PZIbd4X6ws/Dsk
nPTuoI0IYARJK1T6vRJKfqyilAOFVjvjMB1yngTHMuN/wxUeJtjdiP/KnWv2EDGv
a2IKRf1dJpA9x6naLOeV3aSYsiB7KE+fvcLNuFsiyU6Kv9NVfNS9w86mr/AVfUAX
TsNTPVfkiAuqmCFRFkVHq7wyL8edx8dMeJewUlb5sxx/0awabHASpPz5x7OPnOaw
Yf1XC+AecmxJoAuLO/nG
=xSrk
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] typo fixes (coordiante -> coordinate) in am335x

2013-10-19 Thread Jan Lübbe 
On Wed, 2013-08-21 at 00:58 -0700, Tony Lindgren wrote:
> * Zubair Lutfullah  [130715 08:33]:
> > Did a grep for coordiante and replaced them all
> > with coordinate.
> > 
> > This applies to the mfd-next tree.
> 
> This should be safe to apply via the MFD tree as a non-critical
> fix assuming the bootloaders are not yet using this:
> 
> Acked-by: Tony Lindgren 

It seems this didn't get applied. It fixes the touchscreen on a
BeagleBone black with the 7" LCD and we should avoid having people use
the wrong binding.

Samuel or Lee: Could you take this patch?

Thanks,
Jan Lübbe

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v9 4/9] mtd: nand: omap: enable auto-detection of bus-width for omap-nand drivers

2013-10-19 Thread Gupta, Pekon 
Hi Brian,

> From: Brian Norris [mailto:computersforpe...@gmail.com]
> On Thu, Oct 17, 2013 at 09:00:27PM +, Pekon Gupta wrote:
> > > From: Brian Norris [mailto:computersforpe...@gmail.com]
> > > > On Thu, Oct 17, 2013 at 04:42:23AM +, Pekon Gupta wrote:
 [...]

> > > But the real point: you need to clearly communicate what you are
> > > choosing in this patch. Either you want to
> > >
> > >  (1) strictly follow the buswidth provided by the platform or
> > >
> > >  (2) use the nand_base.c BUSWIDTH_AUTO automatic configuration.
> > >
> > Ideally, I would like to go with (2), but that would need other changes
> > in-order to re-configure GPMC with newly parsed ONFI data, which
> > can be a separate patch-set.
> 
> What exactly needs changed to support this? It looks like this omap2
> NAND driver doesn't make assumptions about 8-bit vs. 16-bit until after
> nand_scan_ident(). But maybe there is something I missed.
> 
The GPMC driver will be touched by NAND_BUSWIDTH_AUTO change.
There are two set of configurations in GPMC controller..
(a) device based configurations:
  These are static configurations derived on DT bindings for each
  chip-select (like NAND signal timings, etc). These done on GPMC probe.
(b) ecc-scheme based configurations:
  These are dynamic configurations done in NAND driver in
  chip->ecc.hwctl() and are refreshed at each NAND accesss.

However, 'nand-bus-width' configuration is part of both (1) and (2).
Thus, both 'OMAP NAND driver' and 'GPMC driver' need to be
consistent in programming  'nand-bus-width' otherwise ecc-engine
would not work.
Thus, I'm proceeding with (1) DT based parsing of 'nand-bus-width'.


> > Thus, I would drop this patch for now. And go with (1),
> 
> OK, but to drop this patch entirely would still not be (1); it would
> still leave the possibility of calling nand_scan_ident() twice, and it
> puts you in a middle ground between (1) and (2). That's fine if it works
> for you, but I just want to acknowledge that now: this driver requires
> changes to become either (1) or (2).
> 
I have re-posted [PATCH v10 4/10] with this updates. However, please
take into account that some limitation of dual programming require
such probe. New patch also call nand_scan_ident() twice, but only
on certain pre-determined conditions, not in all failure.
Once I convert to NAND_BUSWIDTH_AUTO these should get clean,
 as I would update both GPMC and NAND driver for this.
(Till then this was most optimal solution I could think of)..


> Does your series need a rebase if we're removing this patch? Or you're
> rewriting/simplifying it to the following two points? (Perhaps it's
> best to separate this portion to its own patch (set) and discussion,
> since it is independent of your ECC rewrite.)
> 
> > with following
> > updates in  omap_nand_probe().
> >
> > (a) perform nand_scan_ident() in "x8" mode, so that ONFI params are
> > read and device-info (chip->writesize, chip->oobsize) are populated.
> 
> OK.
> 
> > (b) Then switch to "x8" or "x16" mode based on "nand-bus-width"
> > as passed from GPMC driver to NAND driver via platform-data.
> >And re-populate mtd->byte, mtd-read_buf, mtd->write_buf.
> 
> I'm not sure if switching buswidth after nand_scan_ident() is really
> supported, but I'll hold off until I see the code you're proposing.
> 
I have re-posted [PATCH v10 4/10] with this updates.
Please accept this ...


with regards, pekon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 09/10] mtd: nand: omap: updated devm_xx for all resource allocation and free calls

2013-10-19 Thread Pekon Gupta 
"Managed Device Resource" or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference: Documentation/driver-model/devres.txt

Though OMAP NAND driver handles freeing of resource allocation in most of
the cases, but using devm_xx provides more clean and effortless approach
to handle all such cases.

- simplifies label for exiting probe during error
  s/out_release_mem_region/return_error

Signed-off-by: Pekon Gupta 
---
 drivers/mtd/nand/omap2.c | 89 
 1 file changed, 37 insertions(+), 52 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4f8efe0..45433f4 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1642,7 +1642,8 @@ static int omap_nand_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   info = kzalloc(sizeof(struct omap_nand_info), GFP_KERNEL);
+   info = devm_kzalloc(&pdev->dev, sizeof(struct omap_nand_info),
+   GFP_KERNEL);
if (!info)
return -ENOMEM;
 
@@ -1667,22 +1668,23 @@ static int omap_nand_probe(struct platform_device *pdev)
if (res == NULL) {
err = -EINVAL;
dev_err(&pdev->dev, "error getting memory resource\n");
-   goto out_free_info;
+   goto return_error;
}
 
info->phys_base = res->start;
info->mem_size = resource_size(res);
 
-   if (!request_mem_region(info->phys_base, info->mem_size,
-   pdev->dev.driver->name)) {
+   if (!devm_request_mem_region(&pdev->dev, info->phys_base,
+   info->mem_size, pdev->dev.driver->name)) {
err = -EBUSY;
-   goto out_free_info;
+   goto return_error;
}
 
-   nand_chip->IO_ADDR_R = ioremap(info->phys_base, info->mem_size);
+   nand_chip->IO_ADDR_R = devm_ioremap(&pdev->dev, info->phys_base,
+   info->mem_size);
if (!nand_chip->IO_ADDR_R) {
err = -ENOMEM;
-   goto out_release_mem_region;
+   goto return_error;
}
 
nand_chip->controller = &info->controller;
@@ -1718,13 +1720,13 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->options |= pdata->devsize;
if (nand_scan_ident(mtd, 1, NULL)) {
err = -ENXIO;
-   goto out_release_mem_region;
+   goto return_error;
}
} else {
/* some genuine failure, because even platform-data
 * (DT binding) says that bus-width is x8 */
err = -ENXIO;
-   goto out_release_mem_region;
+   goto return_error;
}
} else {
/* nand_scan_ident passed with x8 mode */
@@ -1733,7 +1735,7 @@ static int omap_nand_probe(struct platform_device *pdev)
pr_err("%s: incorrect bus-width config\n", DRIVER_NAME);
err = -EINVAL;
err = -ENXIO;
-   goto out_release_mem_region;
+   goto return_error;
}
}
 
@@ -1741,7 +1743,7 @@ static int omap_nand_probe(struct platform_device *pdev)
if ((mtd->oobsize < 64) && (pdata->ecc_opt != OMAP_ECC_HAM1_CODE_HW)) {
pr_err("small page devices are not supported\n");
err = -EINVAL;
-   goto out_release_mem_region;
+   goto return_error;
}
 
/* re-populate low-level callbacks based on xfer modes */
@@ -1769,7 +1771,7 @@ static int omap_nand_probe(struct platform_device *pdev)
if (!info->dma) {
dev_err(&pdev->dev, "DMA engine request failed\n");
err = -ENXIO;
-   goto out_release_mem_region;
+   goto return_error;
} else {
struct dma_slave_config cfg;
 
@@ -1784,7 +1786,7 @@ static int omap_nand_probe(struct platform_device *pdev)
if (err) {
dev_err(&pdev->dev, "DMA engine slave config 
failed: %d\n",
err);
-   goto out_release_mem_region;
+   goto return_error;
}
nand_chip->read_buf   = omap_read_buf_dma_pref;
nand_chip->write_buf  = omap_write_buf_dma_pref;
@@ -1796,30 +1798,32 @@ static int omap_nand_probe(struct platform_device *pdev)
if (inf

[PATCH v10 07/10] mtd: nand: omap: use drivers/mtd/nand/nand_bch.c wrapper for BCH ECC instead of lib/bch.c

2013-10-19 Thread Pekon Gupta 
generic frame-work in mtd/nand/nand_bch.c is a wrapper above lib/bch.h which
encapsulates all control information specific to BCH ecc algorithm in software.
Thus this patch:
(1) replace omap specific implementations with equivalent wrapper in nand_bch.c
so that generic code from nand_bch.c is re-used. like;
omap3_correct_data_bch() -> nand_bch_correct_data()
omap3_free_bch() -> nand_bch_free()
(2) replace direct calls to lib/bch.c with wrapper functions defined in 
nand_bch.c
init_bch() -> nand_bch_init()

Signed-off-by: Pekon Gupta 
---
 drivers/mtd/nand/omap2.c | 96 +++-
 1 file changed, 22 insertions(+), 74 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index c93655e..4f8efe0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 #include 
@@ -140,7 +140,6 @@
 #define BCH_ECC_SIZE1  0x20/* ecc_size1 = 32 */
 
 #define BADBLOCK_MARKER_LENGTH 2
-#define OMAP_ECC_BCH8_POLYNOMIAL   0x201b
 
 #ifdef CONFIG_MTD_NAND_OMAP_BCH
 static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
@@ -173,7 +172,6 @@ struct omap_nand_info {
int buf_len;
struct gpmc_nand_regs   reg;
/* fields specific for BCHx_HW ECC scheme */
-   struct bch_control *bch;
boolis_elm_used;
struct device   *elm_dev;
struct device_node  *of_node;
@@ -1507,43 +1505,7 @@ static int omap_elm_correct_data(struct mtd_info *mtd, 
u_char *data,
 
return stat;
 }
-#endif /* CONFIG_MTD_NAND_OMAP_BCH */
 
-#ifdef CONFIG_MTD_NAND_ECC_BCH
-/**
- * omap3_correct_data_bch - Decode received data and correct errors
- * @mtd: MTD device structure
- * @data: page data
- * @read_ecc: ecc read from nand flash
- * @calc_ecc: ecc read from HW ECC registers
- */
-static int omap3_correct_data_bch(struct mtd_info *mtd, u_char *data,
- u_char *read_ecc, u_char *calc_ecc)
-{
-   int i, count;
-   /* cannot correct more than 8 errors */
-   unsigned int errloc[8];
-   struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
-  mtd);
-
-   count = decode_bch(info->bch, NULL, 512, read_ecc, calc_ecc, NULL,
-  errloc);
-   if (count > 0) {
-   /* correct errors */
-   for (i = 0; i < count; i++) {
-   /* correct data only, not ecc bytes */
-   if (errloc[i] < 8*512)
-   data[errloc[i]/8] ^= 1 << (errloc[i] & 7);
-   pr_debug("corrected bitflip %u\n", errloc[i]);
-   }
-   } else if (count < 0) {
-   pr_err("ecc unrecoverable error\n");
-   }
-   return count;
-}
-#endif /* CONFIG_MTD_NAND_ECC_BCH */
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
 /**
  * omap_write_page_bch - BCH ecc based write page function for entire page
  * @mtd:   mtd info structure
@@ -1660,28 +1622,6 @@ static int is_elm_present(struct omap_nand_info *info,
 }
 #endif /* CONFIG_MTD_NAND_ECC_BCH */
 
-#ifdef CONFIG_MTD_NAND_ECC_BCH
-/**
- * omap3_free_bch - Release BCH ecc resources
- * @mtd: MTD device structure
- */
-static void omap3_free_bch(struct mtd_info *mtd)
-{
-   struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
-  mtd);
-   if (info->bch) {
-   free_bch(info->bch);
-   info->bch = NULL;
-   }
-}
-
-#else
-
-static void omap3_free_bch(struct mtd_info *mtd)
-{
-}
-#endif /* CONFIG_MTD_NAND_ECC_BCH */
-
 static int omap_nand_probe(struct platform_device *pdev)
 {
struct omap_nand_info   *info;
@@ -1714,13 +1654,13 @@ static int omap_nand_probe(struct platform_device *pdev)
info->pdev  = pdev;
info->gpmc_cs   = pdata->cs;
info->reg   = pdata->reg;
-   info->bch   = NULL;
info->of_node   = pdata->of_node;
mtd = &info->mtd;
mtd->priv   = &info->nand;
mtd->name   = dev_name(&pdev->dev);
mtd->owner  = THIS_MODULE;
nand_chip   = &info->nand;
+   nand_chip->ecc.priv = NULL;
nand_chip->options  |= NAND_SKIP_BBTSCAN;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1927,7 +1867,7 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->ecc.bytes= 7;
nand_chip->ecc.strength = 4;
nand_chip->ecc.hwctl= omap3_enable_hwecc_bch;
-   nand_chip->ecc.correct

[PATCH v10 03/10] mtd: nand: omap: cleanup: replace local references with generic framework names

2013-10-19 Thread Pekon Gupta 
This patch updates following in omap_nand_probe() and omap_nand_remove()
- replaces "info->nand" with "nand_chip" (struct nand_chip *nand_chip)
- replaces "info->mtd" with "mtd" (struct mtd_info *mtd)
- white-space and formatting cleanup

Signed-off-by: Pekon Gupta 
---
 drivers/mtd/nand/omap2.c | 112 ---
 1 file changed, 57 insertions(+), 55 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 8d521aa..5596368 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1824,10 +1824,12 @@ static int omap_nand_probe(struct platform_device *pdev)
 {
struct omap_nand_info   *info;
struct omap_nand_platform_data  *pdata;
+   struct mtd_info *mtd;
+   struct nand_chip*nand_chip;
int err;
int i, offset;
-   dma_cap_mask_t mask;
-   unsigned sig;
+   dma_cap_mask_t  mask;
+   unsignedsig;
struct resource *res;
struct mtd_part_parser_data ppdata = {};
 
@@ -1846,17 +1848,16 @@ static int omap_nand_probe(struct platform_device *pdev)
spin_lock_init(&info->controller.lock);
init_waitqueue_head(&info->controller.wq);
 
-   info->pdev = pdev;
-
+   info->pdev  = pdev;
info->gpmc_cs   = pdata->cs;
info->reg   = pdata->reg;
-
-   info->mtd.priv  = &info->nand;
-   info->mtd.name  = dev_name(&pdev->dev);
-   info->mtd.owner = THIS_MODULE;
-
-   info->nand.options  = pdata->devsize;
-   info->nand.options  |= NAND_SKIP_BBTSCAN;
+   mtd = &info->mtd;
+   mtd->priv   = &info->nand;
+   mtd->name   = dev_name(&pdev->dev);
+   mtd->owner  = THIS_MODULE;
+   nand_chip   = &info->nand;
+   nand_chip->options  = pdata->devsize;
+   nand_chip->options  |= NAND_SKIP_BBTSCAN;
 #ifdef CONFIG_MTD_NAND_OMAP_BCH
info->of_node   = pdata->of_node;
 #endif
@@ -1877,16 +1878,16 @@ static int omap_nand_probe(struct platform_device *pdev)
goto out_free_info;
}
 
-   info->nand.IO_ADDR_R = ioremap(info->phys_base, info->mem_size);
-   if (!info->nand.IO_ADDR_R) {
+   nand_chip->IO_ADDR_R = ioremap(info->phys_base, info->mem_size);
+   if (!nand_chip->IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
}
 
-   info->nand.controller = &info->controller;
+   nand_chip->controller = &info->controller;
 
-   info->nand.IO_ADDR_W = info->nand.IO_ADDR_R;
-   info->nand.cmd_ctrl  = omap_hwcontrol;
+   nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
+   nand_chip->cmd_ctrl  = omap_hwcontrol;
 
/*
 * If RDY/BSY line is connected to OMAP then use the omap ready
@@ -1896,26 +1897,26 @@ static int omap_nand_probe(struct platform_device *pdev)
 * device and read status register until you get a failure or success
 */
if (pdata->dev_ready) {
-   info->nand.dev_ready = omap_dev_ready;
-   info->nand.chip_delay = 0;
+   nand_chip->dev_ready = omap_dev_ready;
+   nand_chip->chip_delay = 0;
} else {
-   info->nand.waitfunc = omap_wait;
-   info->nand.chip_delay = 50;
+   nand_chip->waitfunc = omap_wait;
+   nand_chip->chip_delay = 50;
}
 
switch (pdata->xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
-   info->nand.read_buf   = omap_read_buf_pref;
-   info->nand.write_buf  = omap_write_buf_pref;
+   nand_chip->read_buf   = omap_read_buf_pref;
+   nand_chip->write_buf  = omap_write_buf_pref;
break;
 
case NAND_OMAP_POLLED:
-   if (info->nand.options & NAND_BUSWIDTH_16) {
-   info->nand.read_buf   = omap_read_buf16;
-   info->nand.write_buf  = omap_write_buf16;
+   if (nand_chip->options & NAND_BUSWIDTH_16) {
+   nand_chip->read_buf   = omap_read_buf16;
+   nand_chip->write_buf  = omap_write_buf16;
} else {
-   info->nand.read_buf   = omap_read_buf8;
-   info->nand.write_buf  = omap_write_buf8;
+   nand_chip->read_buf   = omap_read_buf8;
+   nand_chip->write_buf  = omap_write_buf8;
}
break;
 
@@ -1944,8 +1945,8 @@ static int omap_nand_probe(struct platform_device *pdev)
err);
goto out_release_mem_region;
}
-   info->nand.read_buf   = o

[PATCH v10 08/10] ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt

2013-10-19 Thread Pekon Gupta 
Updated DTS to replace deprecated binding with newer values
Refer: Documentation/devicetree/bindings/mtd/gpmc-nand.txt

Signed-off-by: Pekon Gupta 
Reviewed-by: Felipe Balbi 
---
 arch/arm/boot/dts/am335x-evm.dts   | 3 +--
 arch/arm/boot/dts/omap3430-sdp.dts | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e8ec875..1aee6ac 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -269,7 +269,6 @@
reg = <0 0 0>; /* CS0, offset 0 */
nand-bus-width = <8>;
ti,nand-ecc-opt = "bch8";
-   gpmc,device-nand = "true";
gpmc,device-width = <1>;
gpmc,sync-clk-ps = <0>;
gpmc,cs-on-ns = <0>;
@@ -296,7 +295,7 @@
 
#address-cells = <1>;
#size-cells = <1>;
-   elm_id = <&elm>;
+   ti,elm-id = <&elm>;
 
/* MTD partition table */
partition@0 {
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts 
b/arch/arm/boot/dts/omap3430-sdp.dts
index e2249bc..501f863 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -105,7 +105,7 @@
reg = <1 0 0x0800>;
nand-bus-width = <8>;
 
-   ti,nand-ecc-opt = "sw";
+   ti,nand-ecc-opt = "ham1";
gpmc,cs-on-ns = <0>;
gpmc,cs-rd-off-ns = <36>;
gpmc,cs-wr-off-ns = <36>;
-- 
1.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 01/10] ARM: OMAP2+: cleaned-up DT support of various ECC schemes

2013-10-19 Thread Pekon Gupta 
OMAP NAND driver support multiple ECC scheme, which can used in different
flavours, depending on in-build Hardware engines present on SoC.

This patch updates following in DT bindings related to sectionion of ecc-schemes
- ti,elm-id: replaces elm_id (maintains backward compatibility)
- ti,nand-ecc-opts: selection of h/w or s/w implementation of an ecc-scheme
depends on ti,elm-id. (supported values ham1, bch4, and bch8)
- maintain backward compatibility to deprecated DT bindings (sw, hw, hw-romcode)

Below table shows different flavours of ecc-schemes supported by OMAP devices
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW  |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W|
|(requires CONFIG_MTD_NAND_ECC_BCH) |   |   |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
|(requires CONFIG_MTD_NAND_OMAP_BCH &&  |   |   |
| ti,elm-id in DT)  |   |   |
+---+---+---+

To optimize footprint of omap2-nand driver, selection of some ECC schemes
also require enabling following Kconfigs, in addition to setting appropriate
DT bindings
- Kconfig:CONFIG_MTD_NAND_ECC_BCHerror detection done in software
- Kconfig:CONFIG_MTD_NAND_OMAP_BCH   error detection done by h/w engine

Signed-off-by: Pekon Gupta 
Reviewed-by: Felipe Balbi 
Acked-by: Tony Lindgren 
---
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  8 +++-
 arch/arm/mach-omap2/gpmc.c | 48 +++---
 include/linux/platform_data/mtd-nand-omap2.h   | 13 +-
 3 files changed, 51 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index df338cb..bfe07e1 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -36,8 +36,12 @@ Optional properties:
"prefetch-dma"  Prefetch enabled sDMA mode
"prefetch-irq"  Prefetch enabled irq mode
 
- - elm_id: Specifies elm device node. This is required to support BCH
-   error correction using ELM module.
+ - elm_id:  use "ti,elm-id" instead
+ - ti,elm-id:  Specifies phandle of the ELM devicetree node.
+   ELM is an on-chip hardware engine on TI SoC which is used for
+   locating ECC errors for BCHx algorithms. SoC devices which have
+   ELM hardware engines should specify this device node in .dtsi
+   Using ELM for ECC error correction frees some CPU cycles.
 
 For inline partiton table parsing (optional):
 
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 579697a..c877129 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1341,14 +1341,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
device_node *np,
 
 #ifdef CONFIG_MTD_NAND
 
-static const char * const nand_ecc_opts[] = {
-   [OMAP_ECC_HAMMING_CODE_DEFAULT] = "sw",
-   [OMAP_ECC_HAMMING_CODE_HW]  = "hw",
-   [OMAP_ECC_HAMMING_CODE_HW_ROMCODE]  = "hw-romcode",
-   [OMAP_ECC_BCH4_CODE_HW] = "bch4",
-   [OMAP_ECC_BCH8_CODE_HW] = "bch8",
-};
-
 static const char * const nand_xfer_types[] = {
[NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
[NAND_OMAP_POLLED]  = "polled",
@@ -1378,13 +1370,41 @@ static int gpmc_probe_nand_child(struct platform_device 
*pdev,
gpmc_nand_data->cs = val;
gpmc_nand_data->of_node = child;
 
-   if (!of_property_read_string(child, "ti,nand-ecc-opt", &s))
-   for (val = 0; val < ARRAY_SIZE(nand_ecc_opts); val++)
-   if (!strcasecmp(s, nand_ecc_opts[val])) {
-   gpmc_nand_data->ecc_opt = val;
-   break;
-   }
+   /* Detect availability of ELM module */
+   gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
+   if (gpmc_nand_data->elm_of_node == NULL)
+   gpmc_nand_data->elm_of_node =
+   of_parse_phandle(child, "elm_id", 0);
+   if (gpmc_nand_data->elm_of_node == NULL)
+   pr_warn("%s: ti,elm-id property not found\n", __func__);
+
+   /* select ecc-scheme for NAND */
+   if (of_property_read_string(child, "ti,nand-ecc-o

[PATCH v10 06/10] mtd: nand: omap: clean-up ecc layout for BCH ecc schemes

2013-10-19 Thread Pekon Gupta 
In current implementation omap3_init_bch_tail() is a common function to
define ecc layout for different BCHx ecc schemes.This patch:
(1) removes omap3_init_bch_tail() and defines ecc layout for individual
ecc-schemes along with populating their nand_chip->ecc data in
omap_nand_probe(). This improves the readability and scalability of
code for add new ecc schemes in future.
(2) removes 'struct nand_bbt_descr bb_descrip_flashbased' because default
nand_bbt_descr in nand_bbt.c matches the same (.len=1 for x8 devices).
(3) add the check to see if NAND device has enough OOB/Spare bytes to
store ECC signature of whole page, as defined by ecc-scheme.

Signed-off-by: Pekon Gupta 
---
 drivers/mtd/nand/omap2.c | 161 ++-
 1 file changed, 62 insertions(+), 99 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 978240b..c93655e 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -139,6 +139,7 @@
 #define BCH_ECC_SIZE0  0x0 /* ecc_size0 = 0, no oob protection */
 #define BCH_ECC_SIZE1  0x20/* ecc_size1 = 32 */
 
+#define BADBLOCK_MARKER_LENGTH 2
 #define OMAP_ECC_BCH8_POLYNOMIAL   0x201b
 
 #ifdef CONFIG_MTD_NAND_OMAP_BCH
@@ -149,17 +150,6 @@ static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd, 
0x41, 0xbc, 0x10};
 
 /* oob info generated runtime depending on ecc algorithm and layout selected */
 static struct nand_ecclayout omap_oobinfo;
-/* Define some generic bad / good block scan pattern which are used
- * while scanning a device for factory marked good / bad blocks
- */
-static uint8_t scan_ff_pattern[] = { 0xff };
-static struct nand_bbt_descr bb_descrip_flashbased = {
-   .options = NAND_BBT_SCANALLPAGES,
-   .offs = 0,
-   .len = 1,
-   .pattern = scan_ff_pattern,
-};
-
 
 struct omap_nand_info {
struct nand_hw_control  controller;
@@ -184,7 +174,6 @@ struct omap_nand_info {
struct gpmc_nand_regs   reg;
/* fields specific for BCHx_HW ECC scheme */
struct bch_control *bch;
-   struct nand_ecclayout   ecclayout;
boolis_elm_used;
struct device   *elm_dev;
struct device_node  *of_node;
@@ -1686,65 +1675,8 @@ static void omap3_free_bch(struct mtd_info *mtd)
}
 }
 
-/**
- * omap3_init_bch_tail - Build an oob layout for BCH ECC correction.
- * @mtd: MTD device structure
- */
-static int omap3_init_bch_tail(struct mtd_info *mtd)
-{
-   int i, steps, offset;
-   struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
-  mtd);
-   struct nand_ecclayout *layout = &info->ecclayout;
-
-   /* build oob layout */
-   steps = mtd->writesize/info->nand.ecc.size;
-   layout->eccbytes = steps*info->nand.ecc.bytes;
-
-   /* do not bother creating special oob layouts for small page devices */
-   if (mtd->oobsize < 64) {
-   pr_err("BCH ecc is not supported on small page devices\n");
-   goto fail;
-   }
-
-   /* reserve 2 bytes for bad block marker */
-   if (layout->eccbytes+2 > mtd->oobsize) {
-   pr_err("no oob layout available for oobsize %d eccbytes %u\n",
-  mtd->oobsize, layout->eccbytes);
-   goto fail;
-   }
-
-   /* ECC layout compatible with RBL for BCH8 */
-   if (info->is_elm_used && (info->nand.ecc.bytes == BCH8_SIZE))
-   offset = 2;
-   else
-   offset = mtd->oobsize - layout->eccbytes;
-
-   /* put ecc bytes at oob tail */
-   for (i = 0; i < layout->eccbytes; i++)
-   layout->eccpos[i] = offset + i;
-
-   if (info->is_elm_used && (info->nand.ecc.bytes == BCH8_SIZE))
-   layout->oobfree[0].offset = 2 + layout->eccbytes * steps;
-   else
-   layout->oobfree[0].offset = 2;
-
-   layout->oobfree[0].length = mtd->oobsize-2-layout->eccbytes;
-   info->nand.ecc.layout = layout;
-
-   if (!(info->nand.options & NAND_BUSWIDTH_16))
-   info->nand.badblock_pattern = &bb_descrip_flashbased;
-   return 0;
-fail:
-   omap3_free_bch(mtd);
-   return -1;
-}
-
 #else
-static int omap3_init_bch_tail(struct mtd_info *mtd)
-{
-   return -1;
-}
+
 static void omap3_free_bch(struct mtd_info *mtd)
 {
 }
@@ -1756,8 +1688,9 @@ static int omap_nand_probe(struct platform_device *pdev)
struct omap_nand_platform_data  *pdata;
struct mtd_info *mtd;
struct nand_chip*nand_chip;
+   struct nand_ecclayout   *ecclayout;
int err;
-   int i, offset;
+   int i;
dma_cap_mask_t  mask;
unsignedsig;
s

[PATCH v10 10/10] mtd: nand: omap: remove selection of BCH ecc-scheme via KConfig

2013-10-19 Thread Pekon Gupta 
With OMAP NAND driver updates, selection of ecc-scheme:
*DT enabled kernel*
depends on ti,nand-ecc-opt and ti,elm-id DT bindings.
*Non DT enabled kernel*
depends on elm_dev and ecc-scheme passed along with platform-data
from board file.

So, selection of ecc-scheme (BCH8 or BCH4) from KConfig can be removed

Signed-off-by: Pekon Gupta 
---
 drivers/mtd/nand/Kconfig | 40 ++--
 1 file changed, 6 insertions(+), 34 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index d885298..93ae6a6 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -96,43 +96,15 @@ config MTD_NAND_OMAP2
 
 config MTD_NAND_OMAP_BCH
depends on MTD_NAND && MTD_NAND_OMAP2 && ARCH_OMAP3
-   tristate "Enable support for hardware BCH error correction"
+   tristate "Support hardware based BCH error correction"
default n
select BCH
-   select BCH_CONST_PARAMS
help
-Support for hardware BCH error correction.
-
-choice
-   prompt "BCH error correction capability"
-   depends on MTD_NAND_OMAP_BCH
-
-config MTD_NAND_OMAP_BCH8
-   bool "8 bits / 512 bytes (recommended)"
-   help
-Support correcting up to 8 bitflips per 512-byte block.
-This will use 13 bytes of spare area per 512 bytes of page data.
-This is the recommended mode, as 4-bit mode does not work
-on some OMAP3 revisions, due to a hardware bug.
-
-config MTD_NAND_OMAP_BCH4
-   bool "4 bits / 512 bytes"
-   help
-Support correcting up to 4 bitflips per 512-byte block.
-This will use 7 bytes of spare area per 512 bytes of page data.
-Note that this mode does not work on some OMAP3 revisions, due to a
-hardware bug. Please check your OMAP datasheet before selecting this
-mode.
-
-endchoice
-
-if MTD_NAND_OMAP_BCH
-config BCH_CONST_M
-   default 13
-config BCH_CONST_T
-   default 4 if MTD_NAND_OMAP_BCH4
-   default 8 if MTD_NAND_OMAP_BCH8
-endif
+ This config enables the ELM hardware engine, which can be used to
+ locate and correct errors when using BCH ECC scheme. This offloads
+ the cpu from doing ECC error searching and correction. However some
+ legacy OMAP families like OMAP2xxx, OMAP3xxx do not have ELM engine
+ so they should not enable this config symbol.
 
 config MTD_NAND_IDS
tristate
-- 
1.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 04/10] mtd: nand: omap: fix device scan: NAND_CMD_READID, NAND_CMD_RESET, CMD_CMD_PARAM use only x8 bus

2013-10-19 Thread Pekon Gupta 
As per comments below, NAND_CMD_RESET, NAND_CMD_READID, and NAND_CMD_PARAM would
work only in x8 mode.
commit 64b37b2a63eb2f80b65c7185f0013f8ffc637ae3
Author: Matthieu CASTET 
AuthorDate: 2012-11-06
Note that nand_scan_ident send command (NAND_CMD_RESET, NAND_CMD_READID, 
NAND_CMD_PARAM), address and read data
The ONFI specificication is not very clear for x16 device if high byte of 
address should be driven to 0,
but according to [1] it should be ok to not drive it during autodetection.

[1]
3.3.2. Target Initialization

[...]
The Read ID and Read Parameter Page commands only use the lower 8-bits of 
the data bus.
The host shall not issue commands that use a word data width on x16 devices 
until the host
determines the device supports a 16-bit data bus width in the parameter 
page.

Thus this patch run nand_scan_ident() with driver configured as x8 device.
Once the NAND device is detected, and its ONFI params are read, the driver
is re-configured based on device-width as passed by DT bindinig 'nand-bus-width'

In-case there is a mis-match between the DT binding 'nand-bus-width' and actual
device-width detected during nand_get_flash_type() then probe returns failure.

All other low-level callback updates happen after the device detection.

Signed-off-by: Pekon Gupta 
---
 drivers/mtd/nand/omap2.c | 45 +
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 5596368..d29edda 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1856,7 +1856,6 @@ static int omap_nand_probe(struct platform_device *pdev)
mtd->name   = dev_name(&pdev->dev);
mtd->owner  = THIS_MODULE;
nand_chip   = &info->nand;
-   nand_chip->options  = pdata->devsize;
nand_chip->options  |= NAND_SKIP_BBTSCAN;
 #ifdef CONFIG_MTD_NAND_OMAP_BCH
info->of_node   = pdata->of_node;
@@ -1904,6 +1903,39 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->chip_delay = 50;
}
 
+   /* scan NAND device connected to chip controller */
+   /* configure driver in x8 mode to read ONFI parameter page, as
+* NAND_CMD_READID & NAND_CMD_PARAM may not work in x16 mode */
+   nand_chip->options &= ~NAND_BUSWIDTH_16;
+   if (nand_scan_ident(mtd, 1, NULL)) {
+   /* nand_scan_ident failed */
+   if (pdata->devsize) {
+   /* may be because of mis-match of device-width,
+* platform data (DT binding) also says its x16 device
+* So re-scan with proper device-width */
+   nand_chip->options |= pdata->devsize;
+   if (nand_scan_ident(mtd, 1, NULL)) {
+   err = -ENXIO;
+   goto out_release_mem_region;
+   }
+   } else {
+   /* some genuine failure, because even platform-data
+* (DT binding) says that bus-width is x8 */
+   err = -ENXIO;
+   goto out_release_mem_region;
+   }
+   } else {
+   /* nand_scan_ident passed with x8 mode */
+   if (pdata->devsize) {
+   /* but platform-data (DT binding) say its x16 device */
+   pr_err("%s: incorrect bus-width config\n", DRIVER_NAME);
+   err = -EINVAL;
+   err = -ENXIO;
+   goto out_release_mem_region;
+   }
+   }
+
+   /* re-populate low-level callbacks based on xfer modes */
switch (pdata->xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
nand_chip->read_buf   = omap_read_buf_pref;
@@ -2011,17 +2043,6 @@ static int omap_nand_probe(struct platform_device *pdev)
}
}
 
-   /* DIP switches on some boards change between 8 and 16 bit
-* bus widths for flash.  Try the other width if the first try fails.
-*/
-   if (nand_scan_ident(mtd, 1, NULL)) {
-   nand_chip->options ^= NAND_BUSWIDTH_16;
-   if (nand_scan_ident(mtd, 1, NULL)) {
-   err = -ENXIO;
-   goto out_release_mem_region;
-   }
-   }
-
/* rom code layout */
if (pdata->ecc_opt == OMAP_ECC_HAM1_CODE_HW) {
 
-- 
1.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 05/10] mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe

2013-10-19 Thread Pekon Gupta 
current implementation in omap3_init_bch() has some redundant code like:
(1) omap3_init_bch() re-probes the DT-binding to detect presence of ELM h/w
engine on SoC. And based on that it selects implemetation of ecc-scheme.
However, this is already done as part of GPMC DT parsing.
(2) As omap3_init_bch() serves as common function for configuring all types of
BCHx ecc-schemes, so there are multiple levels of redudant if..then..else
checks while populating nand_chip->ecc.

This patch make following changes to OMAP NAND driver:
(1) removes omap3_init_bch(): each ecc-scheme is individually configured in
omap_nand_probe() there by removing redundant if..then..else checks.
(2) adds is_elm_present(): re-probing of ELM device via DT is not required as
it's done in GPMC driver probe. Thus is_elm_present() just initializes ELM
driver with NAND probe data, when ecc-scheme with h/w based error-detection
is used.
(3) separates out configuration of different flavours of "BCH4" and "BCH8"
ecc-schemes as given in below table
(4) conditionally compiles callbacks implementations of ecc.hwctl(),
ecc.calculate(), ecc.correct() to avoid warning of un-used functions.

+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW  |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.c)|
| (needs CONFIG_MTD_NAND_ECC_BCH)   |   |   |
|   |   |   |
|OMAP_ECC_BCH4_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
| (needs CONFIG_MTD_NAND_OMAP_BCH &&|   |   |
|ti,elm-id) |   |   |
+---+---+---+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.c)|
| (needs CONFIG_MTD_NAND_ECC_BCH)   |   |   |
|   |   |   |
|OMAP_ECC_BCH8_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
| (needs CONFIG_MTD_NAND_OMAP_BCH &&|   |   |
|ti,elm-id) |   |   |
+---+---+---+

- 'CONFIG_MTD_NAND_ECC_BCH' is generic KConfig required to build lib/bch.c
which is required for ECC error detection done in software.
(mainly used for legacy platforms which do not have on-chip ELM engine)

- 'CONFIG_MTD_NAND_OMAP_BCH' is OMAP specific Kconfig to detemine presence
on ELM h/w engine on SoC.

Signed-off-by: Pekon Gupta 
---
 drivers/mtd/nand/omap2.c | 281 ++-
 1 file changed, 158 insertions(+), 123 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d29edda..978240b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -25,10 +25,8 @@
 #include 
 #include 
 
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
 #include 
 #include 
-#endif
 
 #include 
 
@@ -141,6 +139,8 @@
 #define BCH_ECC_SIZE0  0x0 /* ecc_size0 = 0, no oob protection */
 #define BCH_ECC_SIZE1  0x20/* ecc_size1 = 32 */
 
+#define OMAP_ECC_BCH8_POLYNOMIAL   0x201b
+
 #ifdef CONFIG_MTD_NAND_OMAP_BCH
 static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
@@ -182,14 +182,12 @@ struct omap_nand_info {
u_char  *buf;
int buf_len;
struct gpmc_nand_regs   reg;
-
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
+   /* fields specific for BCHx_HW ECC scheme */
struct bch_control *bch;
struct nand_ecclayout   ecclayout;
boolis_elm_used;
struct device   *elm_dev;
struct device_node  *of_node;
-#endif
 };
 
 /**
@@ -1058,8 +1056,7 @@ static int omap_dev_ready(struct mtd_info *mtd)
}
 }
 
-#ifdef CONFIG_MTD_NAND_OMAP_BCH
-
+#if defined(CONFIG_MTD_NAND_ECC_BCH) || defined(CONFIG_MTD_NAND_OMAP_BCH)
 /**
  * omap3_enable_hwecc_bch - Program OMAP3 GPMC to perform BCH ECC correction
  * @mtd: MTD device structure
@@ -1140,7 +1137,9 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd, 
int mode)
/* Clear ecc and enable bits */
writel(ECCCLEAR | ECC1, info->reg.gpmc_ecc_control);
 }
+#endif
 
+#ifdef CONFIG_MTD_NAND_ECC_BCH
 /**
  * omap3_calculate_ecc_bch4 - Generate 7 bytes of ECC bytes
  * @mtd: MTD device structure
@@ -1225,7 +1224,9 @@ static int omap3_calculate_ecc_bch8(struct mtd

[PATCH v10 00/10] mtd:nand:omap2: clean-up of supported ECC schemes

2013-10-19 Thread Pekon Gupta 

*changes v9 -> v10*
[PATCH 1/10], [PATCH 2/10]
  swapped [PATCH v9 1/9] and [PATCH v9 2/9] so that DT parsing updates
  (with backward compatibility) happen before the deprecation of DT values.
  This way DTB does not break functionally between the patches.
[PATCH 3/10] 
[PATCH 4/10] 
  dropped [PATCH v9 4/9] introducing NAND_BUSWIDTH_AUTO, instead
  using DT 'nand-bus-width' for device bus-width
[PATCH 5/10] 
[PATCH 6/10] 
[PATCH 7/10] 
  separated out drivers/mtd/nand/Kconfig updates into separate [PATCH v10 10/10]
  cleanup: s/info->nand\./nand_chip->
[PATCH 8/10] 
[PATCH 9/10] cleanup: s/out_release_mem_region/return_error
[PATCH 10/10]  spawned from [PATCH v9 8/9] for Kconfig updates


*changes v8 -> v9*
[PATCH 1/9] 
[PATCH 2/9] 
 As per feedbacks from Brian Norris  previous
 revision [PATCH v8 3/6] and [PATCH 4/6] are split into following sub-patches:
- [PATCH 3/9]  replaces local reference with generic names (mtd, nand_chip)
- [PATCH 4/9]  enables auto-detection of bus-width
- [PATCH 5/9]  removes omap3_init_bch: populates ecc-scheme data
- [PATCH 6/9]  removes omap3_init_bch_tail: populates ecc-layout
- [PATCH 7/9]  replaces lib/bch.c with nand_bch.c wrapper
[PATCH 8/9]  v8*
[PATCH 1/6] 
[PATCH 2/6]
- updated DT parsing of "ti,nand-ecc-opts" so that its "ham1" remains
compatible to "sw","hw","hw-romcode"
- updated DT parsing of "ti,elm-id" to retain compatibility to "elm_id"
- using of_parse_phandle() to get ELM device pointer from DT
[PATCH 3..6/6] 


*Changes v6 -> v7*
[PATCH 1/6]  split from [PATCH v6 2/4] as per feedbacks from Brian Norris 

[PATCH 2/6] incorporated feedbacks from DT maintainers
[PATCH 3/6] cleaned and incorporated feedbacks from Brian Norris 

[PATCH 4/6] rebasing changes and cleanup
[PATCH 5/6] updated omap3430-sdp.dts
[PATCH 6/6]  updated for devm_xx


*Changes v5 -> v6*
[PATCH 1/4]: 
- updated DT binding for gpmc-nand based on 'Olof Johansson's feedbacks
http://lists.infradead.org/pipermail/linux-mtd/2013-August/048394.html
- detection of ELM device via ti,elm-id DT node, moved to gpmc.c driver
[PATCH 2/4]
- removed: support for following obselete ECC schemes
OMAP_ECC_HAMMING_CODE_DEFAULT (S/W based 1-bit Hamming ECC)
OMAP_ECC_HAMMING_CODE_HW_ROMCODE (H/W based 1-bit Hamming ECC scheme)
- updated: using omap_oobinfo as chip->ecc.layout for all ecc-schemes
- clean: error messages
[PATCH 3/4] cleaned to include changes for OMAP_ECC_BCH8_CODE_HW only
[PATCH 4/4] updated to include DT property changes


*Changes v4 -> v5*
- Rebased to linux-next 
IMPORTANT: Need to revert commit fb1585b, [PATCH 2/4] part of previous version
http://lists.infradead.org/pipermail/linux-mtd/2013-July/047441.html

- Swapped PATCH-1 & PATCH-2 to maintain bisectibility & compilation dependency
http://lists.infradead.org/pipermail/linux-mtd/2013-July/047461.html

- PATCH-2: re-ordered call to is_elm_present() for later updates ELM driver
- dropped changes in include/linux/platform_data/elm.h (not needed)
- PATCH-3: re-ordered call to is_elm_present() for later updates ELM driver
- Re-formated patch description (replaced tabs with white-spaces)


*Changes v3 -> v4*
(Resent with CC: devicetree-disc...@lists.ozlabs.org)
- [Patch 1/3] removed MTD_NAND_OMAP_BCH8 & MTD_NAND_OMAP_BCH4 from nand/Kconfig
ECC scheme selectable via nand DT (nand-ecc-opt).
- [*] rebased for l2-mtd.git


*Changes v2 -> v3*
(Resent with Author Name fixed)
- PATCH-1: re-arranged code to remove redundancy, added NAND_BUSWIDTH_AUTO
- PATCH-2: updated nand-ecc-opt DT mapping and Documentation
- PATCH-3: code-cleaning + changes to match PATCH-1
- PATCH-4  update DT attribute for ti,nand-ecc-opt 
- received feedback to keep DT mapping independent of linuxism
- PATCH-4: : ARM: dts: AM33xx: updated default ECC scheme in nand-ecc-opt
- independent patch for AM335x-evm.dts update based on PATCH-2


*Changes v1 -> v2*
added   [PATCH 3/4] and [PATCH 4/4]


After this patch series, omap2-nand driver will supports following ECC schemes:
+---+---+---+
| ECC scheme|ECC calculation|Error detection|
+---+---+---+
|OMAP_ECC_HAM1_CODE_HW  |H/W (GPMC) |S/W|
+---+---+---+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW |H/W (GPMC) |S/W (lib/bch.c)|
| (needs CONFIG_MTD_NAND_ECC_BCH)   |   |   |
|   |   |   |
|OMAP_ECC_BCH4_CODE_HW  |H/W (GPMC) |H/W (ELM)  |
| (needs CONFIG_MTD_NAND_OMAP_BCH &&|   |   |
|ti,elm-id) |   |   |
+---+-

[PATCH v10 02/10] mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes

2013-10-19 Thread Pekon Gupta 
OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine
- OMAP_ECC_HAMMING_CODE_HW_ROMCODE
1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible
to ROM code.

This patch combines above multiple ecc-schemes into single implementation:
- OMAP_ECC_HAM1_CODE_HW
1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible
ecc-layout.

Signed-off-by: Pekon Gupta 
Reviewed-by: Felipe Balbi 
Acked-by: Tony Lindgren 
---
 Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 8 
 arch/arm/mach-omap2/board-flash.c   | 2 +-
 drivers/mtd/nand/omap2.c| 9 +++--
 include/linux/platform_data/mtd-nand-omap2.h| 7 +--
 4 files changed, 9 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index bfe07e1..5e1f31b 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -22,10 +22,10 @@ Optional properties:
width of 8 is assumed.
 
  - ti,nand-ecc-opt:A string setting the ECC layout to use. One of:
-
-   "sw"Software method (default)
-   "hw"Hardware method
-   "hw-romcode"gpmc hamming mode method & romcode layout
+   "sw" use "ham1" instead
+   "hw" use "ham1" instead
+   "hw-romcode" use "ham1" instead
+   "ham1"  1-bit Hamming ecc code
"bch4"  4-bit BCH ecc code
"bch8"  8-bit BCH ecc code
 
diff --git a/arch/arm/mach-omap2/board-flash.c 
b/arch/arm/mach-omap2/board-flash.c
index fc20a61..ac82512 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -142,7 +142,7 @@ __init board_nand_init(struct mtd_partition *nand_parts, u8 
nr_parts, u8 cs,
board_nand_data.nr_parts= nr_parts;
board_nand_data.devsize = nand_type;
 
-   board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
+   board_nand_data.ecc_opt = OMAP_ECC_BCH8_CODE_HW;
gpmc_nand_init(&board_nand_data, gpmc_t);
 }
 #endif /* CONFIG_MTD_NAND_OMAP2 || CONFIG_MTD_NAND_OMAP2_MODULE */
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 4ecf0e5..8d521aa 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1993,10 +1993,7 @@ static int omap_nand_probe(struct platform_device *pdev)
}
 
/* select the ecc type */
-   if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_DEFAULT)
-   info->nand.ecc.mode = NAND_ECC_SOFT;
-   else if ((pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW) ||
-   (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE)) {
+   if (pdata->ecc_opt == OMAP_ECC_HAM1_CODE_HW) {
info->nand.ecc.bytes= 3;
info->nand.ecc.size = 512;
info->nand.ecc.strength = 1;
@@ -2025,7 +2022,7 @@ static int omap_nand_probe(struct platform_device *pdev)
}
 
/* rom code layout */
-   if (pdata->ecc_opt == OMAP_ECC_HAMMING_CODE_HW_ROMCODE) {
+   if (pdata->ecc_opt == OMAP_ECC_HAM1_CODE_HW) {
 
if (info->nand.options & NAND_BUSWIDTH_16)
offset = 2;
@@ -2033,7 +2030,7 @@ static int omap_nand_probe(struct platform_device *pdev)
offset = 1;
info->nand.badblock_pattern = &bb_descrip_flashbased;
}
-   omap_oobinfo.eccbytes = 3 * (info->mtd.oobsize/16);
+   omap_oobinfo.eccbytes = 3 * (info->mtd.writesize / 512);
for (i = 0; i < omap_oobinfo.eccbytes; i++)
omap_oobinfo.eccpos[i] = i+offset;
 
diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
b/include/linux/platform_data/mtd-nand-omap2.h
index e4128f1..4da5bfa 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -23,13 +23,8 @@ enum nand_io {
 };
 
 enum omap_ecc {
-   /* 1-bit ecc: stored at end of spare area */
-   OMAP_ECC_HAMMING_CODE_DEFAULT = 0, /* Default, s/w method */
-   OMAP_ECC_HAMMING_CODE_HW, /* gpmc to detect the error */
-   /* 1-bit ecc: stored at beginning of spare area as romcode */
-   OMAP_ECC_HAMMING_CODE_HW_ROMCODE, /* gpmc method & romcode layout */
/* 1-bit  ECC calculation by GPMC, Error detection by Software */
-   OMAP_ECC_HAM1_CODE_HW,
+   OMAP_ECC_HAM1_CODE_HW = 0,
/* 4-bit  ECC calculation by GPMC, Error detection by Software */
OMAP