Re: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM

2016-01-06 Thread Stefan Agner
 + };
> + };
> +
> + usdhc {
> + pinctrl_mmc_cd: gpio_mmc_cd {
> + fsl,pins = <
> +  /* MMC1 CD */
> + MX6QDL_PAD_DI0_PIN4__GPIO4_IO20 0x000b0
> + >;
> + };
> + pinctrl_sd_cd: gpio_sd_cd {
> +     fsl,pins = <
> + /* SD1 CD */
> + MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x000b0
> + >;
> + };
> +  

Re: [PATCH 1/3] ARM: dts: imx7d: add arch timer

2015-12-17 Thread Stefan Agner
On 2015-12-10 15:12, frank...@freescale.com wrote:
> From: Frank Li 
> 
> add cortex a7 arch timer.
> uboot v2016.01-rc2 supported psci basic support.
> smp can be supported by psci

This sounds a bit overly simplified log message. I am not very into this
PSCI topic, is this a prerequisit for the ARM arch timers? Maybe you
could elaborate that a bit more.

Also, I would prefer full sentences and commonly used spellings such as
Cortex-A7, U-Boot etc...

--
Stefan

> 
> Signed-off-by: Frank Li 
> ---
>  arch/arm/boot/dts/imx7d.dtsi | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 489604a..a621af6 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -119,6 +119,15 @@
>   clock-output-names = "osc";
>   };
>  
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>;
> + interrupt-parent = <&intc>;
> + };
> +
>   etr@30086000 {
>   compatible = "arm,coresight-tmc", "arm,primecell";
>   reg = <0x30086000 0x1000>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 3/4] ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11

2015-12-16 Thread Stefan Agner
Hi Matt,

Any chance to get an Ack from you for this patch?

--
Stefan

On 2015-12-07 13:51, Stefan Agner wrote:
> GPLv2-only devicetrees make reuse difficult for software components
> licensed under a different license.
> 
> The consensus is that a GPL/X11 dual-license should allow all necessary
> uses, so relicense the vf610-twr.dts file to this combination.
> 
> CCs were acquired using (updated some email addresses):
> git shortlog -sne --no-merges arch/arm/boot/dts/vf610-cosmic.dts
> 
> CC: Matt Porter 
> Acked-by: Shawn Guo 
> Acked-by: Cory Tusar 
> Acked-by: Olof Johansson 
> Signed-off-by: Stefan Agner 
> ---
>  arch/arm/boot/dts/vf610-cosmic.dts | 40 
> ++
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vf610-cosmic.dts
> b/arch/arm/boot/dts/vf610-cosmic.dts
> index 5447f25..d0559c1 100644
> --- a/arch/arm/boot/dts/vf610-cosmic.dts
> +++ b/arch/arm/boot/dts/vf610-cosmic.dts
> @@ -2,10 +2,42 @@
>   * Copyright 2013 Freescale Semiconductor, Inc.
>   * Copyright 2013 Linaro Limited
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation; either version 2 of the License, or
> - * (at your option) any later version.
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  /dts-v1/;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/2] ARM: dts: vf-colibri: split PWM pinctrl

2015-12-13 Thread Stefan Agner
On 2015-12-13 18:18, Shawn Guo wrote:
> On Wed, Dec 02, 2015 at 02:11:46PM -0800, Stefan Agner wrote:
>> Split PWM pins into separate pinctrl nodes to allow overrides which
>> select pins individually. This is useful for carrier boards which use
>> only one pin for PWM and would like to use the other pin for a
>> different purpose.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>>  arch/arm/boot/dts/vf-colibri.dtsi | 18 ++
>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
>> b/arch/arm/boot/dts/vf-colibri.dtsi
>> index e5949b9..924b660 100644
>> --- a/arch/arm/boot/dts/vf-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf-colibri.dtsi
>> @@ -74,12 +74,12 @@
>>
>>  &pwm0 {
>>  pinctrl-names = "default";
>> -pinctrl-0 = <&pinctrl_pwm0>;
>> +pinctrl-0 = <&pinctrl_pwm0_a &pinctrl_pwm0_c>;
>>  };
>>
>>  &pwm1 {
>>  pinctrl-names = "default";
>> -pinctrl-0 = <&pinctrl_pwm1>;
>> +pinctrl-0 = <&pinctrl_pwm1_b &pinctrl_pwm1_d>;
>>  };
> 
> It may make more sense to define these pwm nodes in the final board
> level dts with only defining the pins that are actually used on the
> board.

Well, if we follow that policy, we would have to remove almost anything
from the -colibri.dtsi device trees...

The Colibri standard defines standard functionality, which is kept
compatible across modules with different SoC's. However, on almost all
pins different functionality is available, and we have some customer
which make use that

So far we followed the policy that we define the pin/device
configuration of the standard functionality in the -colibri.dtsi files
(since this is the most used functionality). This allows us to also
"bug-fix" standard functionality without having to touch customers
(often out-of-tree) device trees.

This change is not different from that approach, it merely splits the
pin configuration in two individual pinctrl nodes. This makes sense for
PWM signals since they can be used individually (compared to, lets say,
I2C, where it is more like "all or nothing")...  It turned out that
several customers used PWM for the display back light, while using
PWM in a different function, therefor that change.

--
Stefan

>>
>>  &uart0 {
>> @@ -195,16 +195,26 @@
>>  >;
>>  };
>>
>> -pinctrl_pwm0: pwm0grp {
>> +pinctrl_pwm0_a: pwm0agrp {
>>  fsl,pins = <
>>  VF610_PAD_PTB0__FTM0_CH00x1182
>> +>;
>> +};
>> +
>> +pinctrl_pwm0_c: pwm0cgrp {
>> +fsl,pins = <
>>  VF610_PAD_PTB1__FTM0_CH10x1182
>>  >;
>>  };
>>
>> -pinctrl_pwm1: pwm1grp {
>> +pinctrl_pwm1_b: pwm1bgrp {
>>  fsl,pins = <
>>  VF610_PAD_PTB8__FTM1_CH00x1182
>> +>;
>> +};
>> +
>> +pinctrl_pwm1_d: pwm1dgrp {
>> +fsl,pins = <
>>  VF610_PAD_PTB9__FTM1_CH10x1182
>>  >;
>>  };
>> --
>> 2.6.2
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 0/4] ARM: dts: vf610: relicense the device trees under GPLv2/X11

2015-12-07 Thread Stefan Agner
On 2015-12-07 13:54, Stephen Warren wrote:
> On 12/07/2015 02:51 PM, Stefan Agner wrote:
>> I collected the Acks I received so far and removed them from the list
>> below. Several Freescale addresses are no longer valid (the once
>> starting with --)... I would interprete the Ack from Yuan Yao as an
>> Ack from Freescale.
>>
>> Matt, you introduced the vf610-cosmic.dts board, is it possible to
>> get an ack for this too? I think you did not receive v1 of this patch
>> due to an old email address, sorry about that.
> 
> I thought I'd already sent an ack for this, but it looks like I forgot 
> somehow.
> 
> Acked-by: Stephen Warren 

Sorry about the confusion, I do have your ack and hence removed you from
the list. However I still put everyone in CC, probably not what I should
have done?

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


[PATCH v2 1/4] ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11

2015-12-07 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vfxxx.dtsi, vf500.dtsi and vf610.dtsi files to
this combination.

CCs were acquired using (updated some email addresses, commented out
bouncing email addresses with --):
git shortlog -sne --no-merges arch/arm/boot/dts/vf???.dtsi

--CC: Chao Fu 
CC: Cosmin Stoica 
CC: Frank Li 
CC: Fugang Duan 
--CC: Huang Shijie 
--CC: Jingchang Lu 
--CC: Xiubo Li 
Acked-by: Shawn Guo 
Acked-by: Lucas Stach 
Acked-by: Stephen Warren 
Acked-by: Cory Tusar 
Acked-by: Sanchayan Maity 
Acked-by: Bhuvanchandra DV 
Acked-by: Yuan Yao 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf500.dtsi | 40 
 arch/arm/boot/dts/vf610.dtsi | 40 
 arch/arm/boot/dts/vfxxx.dtsi | 40 
 3 files changed, 108 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index e976d2f..b94b992 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2013 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.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 #include "skeleton.dtsi"
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 5f8eb1b..c172285 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2013 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.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modi

[PATCH v2 3/4] ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11

2015-12-07 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vf610-twr.dts file to this combination.

CCs were acquired using (updated some email addresses):
git shortlog -sne --no-merges arch/arm/boot/dts/vf610-cosmic.dts

CC: Matt Porter 
Acked-by: Shawn Guo 
Acked-by: Cory Tusar 
Acked-by: Olof Johansson 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-cosmic.dts | 40 ++
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/vf610-cosmic.dts 
b/arch/arm/boot/dts/vf610-cosmic.dts
index 5447f25..d0559c1 100644
--- a/arch/arm/boot/dts/vf610-cosmic.dts
+++ b/arch/arm/boot/dts/vf610-cosmic.dts
@@ -2,10 +2,42 @@
  * Copyright 2013 Freescale Semiconductor, Inc.
  * Copyright 2013 Linaro Limited
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 /dts-v1/;
-- 
2.6.3

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


[PATCH v2 2/4] ARM: dts: vf610-colibri: relicense vf*colibri* under GPLv2/X11

2015-12-07 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vf*colibri* files to this combination.

CCs were acquired using:
git shortlog -sne --no-merges arch/arm/boot/dts/vf*colibri*

Acked-by: Cory Tusar 
Acked-by: Sanchayan Maity 
Acked-by: Bhuvanchandra DV 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi   | 40 ---
 arch/arm/boot/dts/vf-colibri.dtsi   | 40 ---
 arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 ---
 arch/arm/boot/dts/vf500-colibri.dtsi| 40 ---
 arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 42 +
 arch/arm/boot/dts/vf610-colibri.dtsi| 40 ---
 6 files changed, 217 insertions(+), 25 deletions(-)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi 
b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index ed65e0f..b494673 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2014 Toradex AG
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 / {
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index e5949b9..7758791 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2014 Toradex AG
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of 

[PATCH v2 0/4] ARM: dts: vf610: relicense the device trees under GPLv2/X11

2015-12-07 Thread Stefan Agner
I collected the Acks I received so far and removed them from the list
below. Several Freescale addresses are no longer valid (the once
starting with --)... I would interprete the Ack from Yuan Yao as an
Ack from Freescale.

Matt, you introduced the vf610-cosmic.dts board, is it possible to
get an ack for this too? I think you did not receive v1 of this patch
due to an old email address, sorry about that.

vf???.dtsi:
  --Chao Fu 
  Cosmin Stoica 
  Frank Li 
  --Fugang Duan 
  --Huang Shijie 
  --Jingchang Lu 
  --Xiubo Li 

vf610-colibri:
  

vf610-cosmic:
  Matt Porter 

vf610-twr:
  --Chao Fu 
  Cosmin Stoica 
  --Fugang Duan 
  --Jingchang Lu 
  --Xiubo Li 

CC: Bhuvanchandra DV 
CC: Bill Pringlemeir 
--CC: Chao Fu 
CC: Cory Tusar 
CC: Cosmin Stoica 
CC: Frank Li 
--CC: Fugang Duan 
--CC: Huang Shijie 
--CC: Jingchang Lu 
CC: Lucas Stach 
CC: Matt Porter 
CC: Olof Johansson 
CC: Sanchayan Maity 
CC: Shawn Guo 
CC: Stephen Warren 
--CC: Xiubo Li 
CC: Yuan Yao 

Stefan Agner (4):
  ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11
  ARM: dts: vf610-colibri: relicense vf*colibri* under GPLv2/X11
  ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11
  ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11

 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi   | 40 ---
 arch/arm/boot/dts/vf-colibri.dtsi   | 40 ---
 arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 ---
 arch/arm/boot/dts/vf500-colibri.dtsi| 40 ---
 arch/arm/boot/dts/vf500.dtsi| 40 ---
 arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 42 +
 arch/arm/boot/dts/vf610-colibri.dtsi| 40 ---
 arch/arm/boot/dts/vf610-cosmic.dts  | 40 ---
 arch/arm/boot/dts/vf610-twr.dts | 40 ---
 arch/arm/boot/dts/vf610.dtsi| 40 ---
 arch/arm/boot/dts/vfxxx.dtsi| 40 ---
 11 files changed, 397 insertions(+), 45 deletions(-)

-- 
2.6.3

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


[PATCH v2 4/4] ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11

2015-12-07 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vf610-twr.dts file to this combination.

CCs were acquired using (updated some email addresses, commented out
bouncing email addresses with --):
git shortlog -sne --no-merges arch/arm/boot/dts/vf610-twr.dts

--CC: Chao Fu 
CC: Cosmin Stoica 
--CC: Fugang Duan 
--CC: Jingchang Lu 
--CC: Xiubo Li 
Acked-by: Shawn Guo 
Acked-by: Bill Pringlemeir 
Acked-by: Cory Tusar 
Acked-by: Yuan Yao 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 5438ee4..ce937b9 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -1,10 +1,42 @@
 /*
  * Copyright 2013 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.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 /dts-v1/;
-- 
2.6.3

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


[PATCH 2/2] ARM: dts: vf-colibri: add CAN support

2015-12-02 Thread Stefan Agner
Add Colibri standard pinmux for FlexCAN controller instances. CAN
is not a standard Colibri feature, but the datasheet predefines
pins which provide CAN (compatible across some modules). Hence,
add the pinmux on module level.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 924b660..4f798a8 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -23,6 +23,18 @@
status = "okay";
 };
 
+&can0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_flexcan0>;
+   status = "disabled";
+};
+
+&can1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_flexcan1>;
+   status = "disabled";
+};
+
 &dspi1 {
bus-num = <1>;
pinctrl-names = "default";
@@ -125,6 +137,20 @@
 
 &iomuxc {
vf610-colibri {
+   pinctrl_flexcan0: can0grp {
+   fsl,pins = <
+   VF610_PAD_PTB14__CAN0_RX0x31F1
+   VF610_PAD_PTB15__CAN0_TX0x31F2
+   >;
+   };
+
+   pinctrl_flexcan1: can1grp {
+   fsl,pins = <
+   VF610_PAD_PTB16__CAN1_RX0x31F1
+   VF610_PAD_PTB17__CAN1_TX0x31F2
+   >;
+   };
+
pinctrl_gpio_ext: gpio_ext {
fsl,pins = <
VF610_PAD_PTD10__GPIO_890x22ed /* 
EXT_IO_0 */
-- 
2.6.2

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


[PATCH 1/2] ARM: dts: vf-colibri: split PWM pinctrl

2015-12-02 Thread Stefan Agner
Split PWM pins into separate pinctrl nodes to allow overrides which
select pins individually. This is useful for carrier boards which use
only one pin for PWM and would like to use the other pin for a
different purpose.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index e5949b9..924b660 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -74,12 +74,12 @@
 
 &pwm0 {
pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_pwm0>;
+   pinctrl-0 = <&pinctrl_pwm0_a &pinctrl_pwm0_c>;
 };
 
 &pwm1 {
pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_pwm1>;
+   pinctrl-0 = <&pinctrl_pwm1_b &pinctrl_pwm1_d>;
 };
 
 &uart0 {
@@ -195,16 +195,26 @@
>;
};
 
-   pinctrl_pwm0: pwm0grp {
+   pinctrl_pwm0_a: pwm0agrp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
+   >;
+   };
+
+   pinctrl_pwm0_c: pwm0cgrp {
+   fsl,pins = <
VF610_PAD_PTB1__FTM0_CH10x1182
>;
};
 
-   pinctrl_pwm1: pwm1grp {
+   pinctrl_pwm1_b: pwm1bgrp {
fsl,pins = <
VF610_PAD_PTB8__FTM1_CH00x1182
+   >;
+   };
+
+   pinctrl_pwm1_d: pwm1dgrp {
+   fsl,pins = <
VF610_PAD_PTB9__FTM1_CH10x1182
>;
};
-- 
2.6.2

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


Re: [PATCH 0/4] ARM: dts: vf610: relicense the device trees under GPLv2/X11

2015-12-02 Thread Stefan Agner
Hi,

[added latest email address of Matt Porter]

There are only a few Acks missing.

I still miss an answer from a Freescale developer. Yuan, Cosmin or
Frank, any chance to get an ack on this?

--
Stefan


On 2015-11-23 15:57, Stefan Agner wrote:
> The GPLv2 license makes it impractical for other software components
> licensed under another license to use our device trees. To fix this,
> and make our device tree usable by other software components, relicense
> them under a GPLv2/X11 dual-license.
> 
> In order to get this accepted, we *need* all contributors to the Vybrid
> device tree files to send an ack to the patches applying on a file they
> contributed on.
> 
> I think some Freescale email addresses are not valid anymore, can someone
> from Freescale make an ack on their behalf?
> 
> The needed Acked-by by device tree are:
> 
> vf???.dtsi:
>   Bhuvanchandra DV 
>   Chao Fu 
>   Cory Tusar 
>   Cosmin Stoica 
>   Frank Li 
>   Fugang Duan 
>   Huang Shijie 
>   Jingchang Lu 
>   Lucas Stach 
>   Sanchayan Maity 
>   Shawn Guo 
>   Stephen Warren 
>   Xiubo Li 
>   Yuan Yao 
> 
> vf610-colibri:
>   Bhuvanchandra DV 
>   Cory Tusar 
>   Sanchayan Maity 
> 
> vf610-cosmic:
>   Cory Tusar 
>   Matt Porter 
>   Olof Johansson 
>   Shawn Guo 
> 
> vf610-twr:
>   Bill Pringlemeir 
>   Chao Fu 
>   Cory Tusar 
>   Cosmin Stoica 
>   Fugang Duan 
>   Jingchang Lu 
>   Shawn Guo 
>   Xiubo Li 
> 
> CC: Bhuvanchandra DV 
> CC: Bill Pringlemeir 
> CC: Chao Fu 
> CC: Cory Tusar 
> CC: Cosmin Stoica 
> CC: Frank Li 
> CC: Fugang Duan 
> CC: Huang Shijie 
> CC: Jingchang Lu 
> CC: Jingchang Lu 
> CC: Lucas Stach 
> CC: Matt Porter 
> CC: Olof Johansson 
> CC: Sanchayan Maity 
> CC: Shawn Guo 
> CC: Stephen Warren 
> CC: Xiubo Li 
> CC: Yuan Yao 
> 
> Stefan Agner (4):
>   ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11
>   ARM: dts: vf610-colibri: relicense vf*colibri* under GPLv2/X11
>   ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11
>   ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11
> 
>  arch/arm/boot/dts/vf-colibri-eval-v3.dtsi   | 40 ---
>  arch/arm/boot/dts/vf-colibri.dtsi   | 40 ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 ---
>  arch/arm/boot/dts/vf500-colibri.dtsi| 40 ---
>  arch/arm/boot/dts/vf500.dtsi| 40 ---
>  arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 42 
> +
>  arch/arm/boot/dts/vf610-colibri.dtsi| 40 ---
>  arch/arm/boot/dts/vf610-cosmic.dts  | 40 ---
>  arch/arm/boot/dts/vf610-twr.dts | 40 ---
>  arch/arm/boot/dts/vf610.dtsi| 40 ---
>  arch/arm/boot/dts/vfxxx.dtsi| 40 ---
>  11 files changed, 397 insertions(+), 45 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: dts: vf610: use reset values for L2 cache latencies

2015-12-02 Thread Stefan Agner
On 2015-12-02 00:13, Shawn Guo wrote:
> On Mon, Nov 30, 2015 at 05:59:26PM -0800, Stefan Agner wrote:
>> Linux on Vybrid used several different L2 latencies so far, none
>> of them seem to be the right ones. According to the application note
>> AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
>> on CPU clock and is inside the L2 cache controller, whereas the data
>> portion is stored in the external SRAM running on platform clock.
>> Hence it is likely that the correct value requires a higher data
>> latency then tag latency.
>> 
>> These are the values which have been used so far:
>> - The mainline values:
>>   arm,data-latency = <1 1 1>;
>>   arm,tag-latency = <2 2 2>;
>>   Those values have lead to problems on higher clocks. They look
>>   like a poor translation from the reset values (missing +1 offset
>>   and a mix up between tag/latency values).
>> - The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
>>   arm,data-latency = <4 2 3>
>>   arm,tag-latency = <4 2 3>
>>   The cache initialization function along with the value matches the
>>   i.MX6 code from the same kernel, so it seems that those values have
>>   just been copied.
>> - The Colibri values:
>>   arm,data-latency = <2 1 2>;
>>   arm,tag-latency = <3 2 3>;
>>   Those were a mix between the values of the Linux 3.0 based BSP and
>>   the mainline values above.
>> - The SoC Reset values (converted to DT notation):
>>   arm,data-latency = <3 3 3>;
>>   arm,tag-latency = <2 2 2>;
>> 
>> So far there is no official statement on what the correct values are.
>> See also the related Freescale community thread:
>> https://community.freescale.com/message/579785#579785
>> 
>> For now, the reset values seem to be the best bet. Remove all other
>> "bogus" values and use the reset value on vf610.dtsi level.
>> 
>> Signed-off-by: Stefan Agner 
>> ---
>> Hi Shawn,
>> 
>> Any chance to get this into 4.4?
> 
> I can try.  Generally, upstream maintainers are becoming more strict for
> -rc inclusion after -rc3 phase.  Do you have any user stories about why
> this is a critical/urgent fix?  If we send this a critical fix for 4.4-rc
> inclusion, do we need to Cc stable?

It came up a while ago on Freescale community, but I think that user
used downstream BSP's:
https://community.freescale.com/thread/332326

The Colibri VF61 board overwrites the latency, so it is not really
critical for this board.

The Freescale Tower runs at 400MHz by default, but has a CPU which would
support up to 500MHz. I am pretty sure with 500MHz CPU clock, things
will go south with current settings.

Regarding stable: Would probably be consistent...

--
Stefan


> 
> Shawn
> 
>> 
>> --
>> Stefan
>> 
>>  arch/arm/boot/dts/vf610-colibri.dtsi | 5 -
>>  arch/arm/boot/dts/vf610.dtsi | 2 +-
>>  2 files changed, 1 insertion(+), 6 deletions(-)
>> 
>> diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi 
>> b/arch/arm/boot/dts/vf610-colibri.dtsi
>> index 19fe045..2d7eab7 100644
>> --- a/arch/arm/boot/dts/vf610-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf610-colibri.dtsi
>> @@ -18,8 +18,3 @@
>>  reg = <0x8000 0x1000>;
>>  };
>>  };
>> -
>> -&L2 {
>> -arm,data-latency = <2 1 2>;
>> -arm,tag-latency = <3 2 3>;
>> -};
>> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
>> index 5f8eb1b..58bc6e4 100644
>> --- a/arch/arm/boot/dts/vf610.dtsi
>> +++ b/arch/arm/boot/dts/vf610.dtsi
>> @@ -19,7 +19,7 @@
>>  reg = <0x40006000 0x1000>;
>>  cache-unified;
>>  cache-level = <2>;
>> -arm,data-latency = <1 1 1>;
>> +arm,data-latency = <3 3 3>;
>>  arm,tag-latency = <2 2 2>;
>>  };
>>  };
>> --
>> 2.6.2
>> 
>> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: vf610: use reset values for L2 cache latencies

2015-11-30 Thread Stefan Agner
Linux on Vybrid used several different L2 latencies so far, none
of them seem to be the right ones. According to the application note
AN4947 ("Understanding Vybrid Architecture"), the tag portion runs
on CPU clock and is inside the L2 cache controller, whereas the data
portion is stored in the external SRAM running on platform clock.
Hence it is likely that the correct value requires a higher data
latency then tag latency.

These are the values which have been used so far:
- The mainline values:
  arm,data-latency = <1 1 1>;
  arm,tag-latency = <2 2 2>;
  Those values have lead to problems on higher clocks. They look
  like a poor translation from the reset values (missing +1 offset
  and a mix up between tag/latency values).
- The Linux 3.0 (SoC vendor BSP) values (converted to DT notation):
  arm,data-latency = <4 2 3>
  arm,tag-latency = <4 2 3>
  The cache initialization function along with the value matches the
  i.MX6 code from the same kernel, so it seems that those values have
  just been copied.
- The Colibri values:
  arm,data-latency = <2 1 2>;
  arm,tag-latency = <3 2 3>;
  Those were a mix between the values of the Linux 3.0 based BSP and
  the mainline values above.
- The SoC Reset values (converted to DT notation):
  arm,data-latency = <3 3 3>;
  arm,tag-latency = <2 2 2>;

So far there is no official statement on what the correct values are.
See also the related Freescale community thread:
https://community.freescale.com/message/579785#579785

For now, the reset values seem to be the best bet. Remove all other
"bogus" values and use the reset value on vf610.dtsi level.

Signed-off-by: Stefan Agner 
---
Hi Shawn,

Any chance to get this into 4.4?

--
Stefan

 arch/arm/boot/dts/vf610-colibri.dtsi | 5 -
 arch/arm/boot/dts/vf610.dtsi | 2 +-
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi 
b/arch/arm/boot/dts/vf610-colibri.dtsi
index 19fe045..2d7eab7 100644
--- a/arch/arm/boot/dts/vf610-colibri.dtsi
+++ b/arch/arm/boot/dts/vf610-colibri.dtsi
@@ -18,8 +18,3 @@
reg = <0x8000 0x1000>;
};
 };
-
-&L2 {
-   arm,data-latency = <2 1 2>;
-   arm,tag-latency = <3 2 3>;
-};
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 5f8eb1b..58bc6e4 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -19,7 +19,7 @@
reg = <0x40006000 0x1000>;
cache-unified;
cache-level = <2>;
-   arm,data-latency = <1 1 1>;
+   arm,data-latency = <3 3 3>;
arm,tag-latency = <2 2 2>;
};
 };
-- 
2.6.2

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


Re: [PATCH v3 1/4] iio: adc: add IMX7D ADC driver support

2015-11-24 Thread Stefan Agner
Hi Haibo,

Some comments below:

On 2015-11-20 07:48, Haibo Chen wrote:
> Freescale i.MX7D soc contains a new ADC IP. This patch add this ADC
> driver support, and the driver only support ADC software trigger.
> 
> Signed-off-by: Haibo Chen 
> ---
>  drivers/iio/adc/Kconfig |   9 +
>  drivers/iio/adc/Makefile|   1 +
>  drivers/iio/adc/imx7d_adc.c | 570 
> 
>  3 files changed, 580 insertions(+)
>  create mode 100644 drivers/iio/adc/imx7d_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7868c74..bf0611c 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -194,6 +194,15 @@ config HI8435
> This driver can also be built as a module. If so, the module will be
> called hi8435.
>  
> +config IMX7D_ADC
> + tristate "IMX7D ADC driver"
> + depends on OF

Hm, not sure, but shouldn't we use a proper depends here? Otherwise this
will show up as modules in all kinds of distributions.

> + help
> +   Say yes here to build support for IMX7D ADC.
> +
> +   This driver can also be built as a module. If so, the module will be
> +   called imx7d_adc.
> +
>  config LP8788_ADC
>   tristate "LP8788 ADC driver"
>   depends on MFD_LP8788
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 99b37a9..282ffc01 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
>  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_HI8435) += hi8435.o
> +obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1027) += max1027.o
>  obj-$(CONFIG_MAX1363) += max1363.o
> diff --git a/drivers/iio/adc/imx7d_adc.c b/drivers/iio/adc/imx7d_adc.c
> new file mode 100644
> index 000..d9547bf
> --- /dev/null
> +++ b/drivers/iio/adc/imx7d_adc.c
> @@ -0,0 +1,570 @@
> +/*
> + * Freescale i.MX7D ADC driver
> + *
> + * Copyright (C) 2015 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Can you sort these alphabetically

> +
> +#include 
> +#include 
> +#include 
> +
> +/* ADC register */
> +#define IMX7D_REG_ADC_CH_A_CFG1  0x00
> +#define IMX7D_REG_ADC_CH_A_CFG2  0x10
> +#define IMX7D_REG_ADC_CH_B_CFG1  0x20
> +#define IMX7D_REG_ADC_CH_B_CFG2  0x30
> +#define IMX7D_REG_ADC_CH_C_CFG1  0x40
> +#define IMX7D_REG_ADC_CH_C_CFG2  0x50
> +#define IMX7D_REG_ADC_CH_D_CFG1  0x60
> +#define IMX7D_REG_ADC_CH_D_CFG2  0x70
> +#define IMX7D_REG_ADC_CH_SW_CFG  0x80
> +#define IMX7D_REG_ADC_TIMER_UNIT 0x90
> +#define IMX7D_REG_ADC_DMA_FIFO   0xa0
> +#define IMX7D_REG_ADC_FIFO_STATUS0xb0
> +#define IMX7D_REG_ADC_INT_SIG_EN 0xc0
> +#define IMX7D_REG_ADC_INT_EN 0xd0
> +#define IMX7D_REG_ADC_INT_STATUS 0xe0
> +#define IMX7D_REG_ADC_CHA_B_CNV_RSLT 0xf0
> +#define IMX7D_REG_ADC_CHC_D_CNV_RSLT 0x100
> +#define IMX7D_REG_ADC_CH_SW_CNV_RSLT 0x110
> +#define IMX7D_REG_ADC_DMA_FIFO_DAT   0x120
> +#define IMX7D_REG_ADC_ADC_CFG0x130
> +
> +#define IMX7D_EACH_CHANNEL_REG_SHIF  0x20

I would call that OFFSET, SHIFT is typically used for a bit offset
within a register.

> +
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_EN (0x1 << 31)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_DISABLE(0x0 << 
> 31)

I would just define the _EN definition (along with using BIT).
Bitshifting a 0 is not really useful.

> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SINGLE BIT(30)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_AVG_EN BIT(29)
> +#define IMX7D_REG_ADC_CH_CFG1_CHANNEL_SEL_SHIF   24
> +
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_4  (0x0 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_8  (0x1 << 
> 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_16 (0x2 << 12)
> +#define IMX7D_REG_ADC_CH_CFG2_AVG_NUM_32 (0x3 << 12)
> +
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_4   (0x0 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_8   (0x1 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT_PRE_DIV_16  (0x2 << 29)
> +#define IMX7D_REG_ADC_TIMER_UNIT

Re: [PATCH] ARM: dts: vf6xx: Cosmic+: M4(nommu) initial support

2015-11-24 Thread Stefan Agner
On 2015-11-23 19:26, Shawn Guo wrote:
> On Sun, Oct 25, 2015 at 11:20:56PM +0530, Afzal Mohammed wrote:
>> Minimal Cortex-M4 device tree to boot Linux to shell. M4 is booted via
>> Cortex-A5 running Linux using Stefan Agner's  "m4boot"
>> utility.
>>
>> Signed-off-by: Afzal Mohammed 
> 
> Stefan,
> 
> Are you okay with this patch?

Looks good to me:

Acked-by: Stefan Agner 

--
Stefan


>> ---
>>  arch/arm/boot/dts/Makefile   |  1 +
>>  arch/arm/boot/dts/vf610m4-cosmic.dts | 90 
>> 
>>  2 files changed, 91 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/vf610m4-cosmic.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index bb8fa023d574..06a1a7a1d104 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -347,6 +347,7 @@ dtb-$(CONFIG_SOC_VF610) += \
>>  vf610-colibri-eval-v3.dtb \
>>  vf610m4-colibri.dtb \
>>  vf610-cosmic.dtb \
>> +vf610m4-cosmic.dtb \
>>  vf610-twr.dtb
>>  dtb-$(CONFIG_ARCH_MXS) += \
>>  imx23-evk.dtb \
>> diff --git a/arch/arm/boot/dts/vf610m4-cosmic.dts 
>> b/arch/arm/boot/dts/vf610m4-cosmic.dts
>> new file mode 100644
>> index ..8944a2d2054c
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/vf610m4-cosmic.dts
>> @@ -0,0 +1,90 @@
>> +/*
>> + * Device tree for Cosmic+ VF6xx Cortex-M4 support
>> + *
>> + * Copyright (C) 2015
>> + *
>> + * Based on vf610m4 Colibri
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "vf610m4.dtsi"
>> +
>> +/ {
>> +model = "VF610 Cortex-M4";
>> +compatible = "fsl,vf610m4";
>> +};
>> +
>> +&gpio0 {
>> +status = "disabled";
>> +};
>> +
>> +&gpio1 {
>> +status = "disabled";
>> +};
>> +
>> +&gpio2 {
>> +status = "disabled";
>> +};
>> +
>> +&gpio3 {
>> +status = "disabled";
>> +};
>> +
>> +&gpio4 {
>> +status = "disabled";
>> +};
>> +
>> +&uart3 {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&pinctrl_uart3>;
>> +status = "okay";
>> +};
>> +
>> +&iomuxc {
>> +vf610-cosmic {
>> +pinctrl_uart3: uart3grp {
>> +fsl,pins = <
>> +VF610_PAD_PTA20__UART3_TX   0x21a2
>> +VF610_PAD_PTA21__UART3_RX   0x21a1
>> +>;
>> +};
>> +};
>> +};
>> --
>> 2.5.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] ARM: dts: vf610-colibri: relicense vf*colibri* under GPLv2/X11

2015-11-23 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vf*colibri* files to this combination.

CCs were acquired using:
git shortlog -sne --no-merges arch/arm/boot/dts/vf*colibri*

CC: Bhuvanchandra DV 
CC: Cory Tusar 
CC: Sanchayan Maity 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi   | 40 ---
 arch/arm/boot/dts/vf-colibri.dtsi   | 40 ---
 arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 ---
 arch/arm/boot/dts/vf500-colibri.dtsi| 40 ---
 arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 42 +
 arch/arm/boot/dts/vf610-colibri.dtsi| 40 ---
 6 files changed, 217 insertions(+), 25 deletions(-)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi 
b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index ed65e0f..b494673 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2014 Toradex AG
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 / {
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index e5949b9..7758791 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2014 Toradex AG
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and 

[PATCH 4/4] ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11

2015-11-23 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vf610-twr.dts file to this combination.

CCs were acquired using (updated some email addresses):
git shortlog -sne --no-merges arch/arm/boot/dts/vf610-twr.dts

CC: Bill Pringlemeir 
CC: Chao Fu 
CC: Cory Tusar 
CC: Cosmin Stoica 
CC: Fugang Duan 
CC: Jingchang Lu 
CC: Shawn Guo 
CC: Xiubo Li 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 5438ee4..ce937b9 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -1,10 +1,42 @@
 /*
  * Copyright 2013 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.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 /dts-v1/;
-- 
2.6.2

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


[PATCH 3/4] ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11

2015-11-23 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vf610-twr.dts file to this combination.

CCs were acquired using (updated some email addresses):
git shortlog -sne --no-merges arch/arm/boot/dts/vf610-cosmic.dts

CC: Cory Tusar 
CC: Matt Porter 
CC: Olof Johansson 
CC: Shawn Guo 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-cosmic.dts | 40 ++
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/vf610-cosmic.dts 
b/arch/arm/boot/dts/vf610-cosmic.dts
index 5447f25..d0559c1 100644
--- a/arch/arm/boot/dts/vf610-cosmic.dts
+++ b/arch/arm/boot/dts/vf610-cosmic.dts
@@ -2,10 +2,42 @@
  * Copyright 2013 Freescale Semiconductor, Inc.
  * Copyright 2013 Linaro Limited
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 /dts-v1/;
-- 
2.6.2

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


[PATCH 0/4] ARM: dts: vf610: relicense the device trees under GPLv2/X11

2015-11-23 Thread Stefan Agner
The GPLv2 license makes it impractical for other software components
licensed under another license to use our device trees. To fix this,
and make our device tree usable by other software components, relicense
them under a GPLv2/X11 dual-license.

In order to get this accepted, we *need* all contributors to the Vybrid
device tree files to send an ack to the patches applying on a file they
contributed on.

I think some Freescale email addresses are not valid anymore, can someone
from Freescale make an ack on their behalf?

The needed Acked-by by device tree are:

vf???.dtsi:
  Bhuvanchandra DV 
  Chao Fu 
  Cory Tusar 
  Cosmin Stoica 
  Frank Li 
  Fugang Duan 
  Huang Shijie 
  Jingchang Lu 
  Lucas Stach 
  Sanchayan Maity 
  Shawn Guo 
  Stephen Warren 
  Xiubo Li 
  Yuan Yao 

vf610-colibri:
  Bhuvanchandra DV 
  Cory Tusar 
  Sanchayan Maity 

vf610-cosmic:
  Cory Tusar 
  Matt Porter 
  Olof Johansson 
  Shawn Guo 

vf610-twr:
  Bill Pringlemeir 
  Chao Fu 
  Cory Tusar 
  Cosmin Stoica 
  Fugang Duan 
  Jingchang Lu 
  Shawn Guo 
  Xiubo Li 

CC: Bhuvanchandra DV 
CC: Bill Pringlemeir 
CC: Chao Fu 
CC: Cory Tusar 
CC: Cosmin Stoica 
CC: Frank Li 
CC: Fugang Duan 
CC: Huang Shijie 
CC: Jingchang Lu 
CC: Jingchang Lu 
CC: Lucas Stach 
CC: Matt Porter 
CC: Olof Johansson 
CC: Sanchayan Maity 
CC: Shawn Guo 
CC: Stephen Warren 
CC: Xiubo Li 
CC: Yuan Yao 

Stefan Agner (4):
  ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11
  ARM: dts: vf610-colibri: relicense vf*colibri* under GPLv2/X11
  ARM: dts: vf610-cosmic: relicense vf610-cosmic.dts under GPLv2/X11
  ARM: dts: vf610-twr: relicense vf610-twr.dts under GPLv2/X11

 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi   | 40 ---
 arch/arm/boot/dts/vf-colibri.dtsi   | 40 ---
 arch/arm/boot/dts/vf500-colibri-eval-v3.dts | 40 ---
 arch/arm/boot/dts/vf500-colibri.dtsi| 40 ---
 arch/arm/boot/dts/vf500.dtsi| 40 ---
 arch/arm/boot/dts/vf610-colibri-eval-v3.dts | 42 +
 arch/arm/boot/dts/vf610-colibri.dtsi| 40 ---
 arch/arm/boot/dts/vf610-cosmic.dts  | 40 ---
 arch/arm/boot/dts/vf610-twr.dts | 40 ---
 arch/arm/boot/dts/vf610.dtsi| 40 ---
 arch/arm/boot/dts/vfxxx.dtsi| 40 ---
 11 files changed, 397 insertions(+), 45 deletions(-)

-- 
2.6.2

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


[PATCH 1/4] ARM: dts: vf610: relicense vf???.dtsi under GPLv2/X11

2015-11-23 Thread Stefan Agner
GPLv2-only devicetrees make reuse difficult for software components
licensed under a different license.

The consensus is that a GPL/X11 dual-license should allow all necessary
uses, so relicense the vfxxx.dtsi, vf500.dtsi and vf610.dtsi files to
this combination.

CCs were acquired using (updated some email addresses):
git shortlog -sne --no-merges arch/arm/boot/dts/vf???.dtsi

CC: Bhuvanchandra DV 
CC: Chao Fu 
CC: Cory Tusar 
CC: Cosmin Stoica 
CC: Frank Li 
CC: Fugang Duan 
CC: Huang Shijie 
CC: Jingchang Lu 
CC: Lucas Stach 
CC: Sanchayan Maity 
CC: Shawn Guo 
CC: Stephen Warren 
CC: Xiubo Li 
CC: Yuan Yao 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf500.dtsi | 40 
 arch/arm/boot/dts/vf610.dtsi | 40 
 arch/arm/boot/dts/vfxxx.dtsi | 40 
 3 files changed, 108 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index e976d2f..b94b992 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2013 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.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 #include "skeleton.dtsi"
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 5f8eb1b..c172285 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -1,10 +1,42 @@
 /*
  * Copyright 2013 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.
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and

Re: [PATCH] ARM: dts: vfxxx: Include support for dspi[23] functionality.

2015-11-18 Thread Stefan Agner
Verified too, looks good to me.

Acked-by: Stefan Agner 

--
Stefan

On 2015-11-18 19:54, Cory Tusar wrote:
> Extend the existing Vybrid DSPI devicetree implementation to also
> describe the dspi2 and dspi3 functional blocks.
> 
> Signed-off-by: Cory Tusar 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 1cca43a..858e60a 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -453,6 +453,30 @@
>   status = "disabled";
>   };
>  
> + dspi2: dspi2@400ac000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-dspi";
> + reg = <0x400ac000 0x1000>;
> + interrupts = <69 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_DSPI2>;
> + clock-names = "dspi";
> + spi-num-chipselects = <2>;
> + status = "disabled";
> + };
> +
> + dspi3: dspi3@400ad000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-dspi";
> + reg = <0x400ad000 0x1000>;
> + interrupts = <70 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_DSPI3>;
> + clock-names = "dspi";
> + spi-num-chipselects = <2>;
> + status = "disabled";
> + };
> +
>   adc1: adc@400bb000 {
>   compatible = "fsl,vf610-adc";
>   reg = <0x400bb000 0x1000>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: dts: vfxxx: Fix dspi[01] spi-num-chipselects.

2015-11-18 Thread Stefan Agner
On 2015-11-18 19:54, Cory Tusar wrote:
> Per the Vybrid Reference Manual (section 3.8.6.1), dspi0 has 6 chip
> select signals associated with it, while dspi1 has only 4.

That is right, verified by in my RM!

Acked-by: Stefan Agner 

> 
> Signed-off-by: Cory Tusar 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 6736bae..1cca43a 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -158,7 +158,7 @@
>   interrupts = <67 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = <&clks VF610_CLK_DSPI0>;
>   clock-names = "dspi";
> - spi-num-chipselects = <5>;
> + spi-num-chipselects = <6>;
>   status = "disabled";
>   };
>  
> @@ -170,7 +170,7 @@
>   interrupts = <68 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = <&clks VF610_CLK_DSPI1>;
>   clock-names = "dspi";
> - spi-num-chipselects = <5>;
> + spi-num-chipselects = <4>;
>   status = "disabled";
>   };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: imx: clk-vf610: fix SAI clock tree

2015-11-18 Thread Stefan Agner
Hi Shawn,

Any thoughts on that patchset? I kind of hoped that it would make it
into 4.4 since it actually fixes issues (at least 1 and 2)... That said,
I don't think it is stable material since it also breaks the device
tree...

--
Stefan

On 2015-10-17 21:05, Stefan Agner wrote:
> The Synchronous Audio Interface (SAI) instances are clocked by
> independent clocks: The bus clock and the audio clock (as shown in
> Figure 51-1 in the Vybrid Reference Manual). The clock gates in
> CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access
> tests to the registers with/without gating those clocks have shown.
> The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1,
> followed by a clock divider (SAIx_DIV). Currently, the parent of
> the bus clock gates has been assigned to SAIx_DIV, which is not
> involved in the bus clock path for the SAI instances (see chapter
> 9.10.12, SAI clocking in the Vybrid Reference Manual).
> 
> Fix this by define the parent clock of VF610_CLK_SAIx to be the bus
> clock.
> 
> If the driver needs the audio clock (when used in master mode), a
> fixed device tree is required which assign the audio clock properly
> to VF610_CLK_SAIx_DIV.
> 
> Signed-off-by: Stefan Agner 
> ---
> Hi all,
> 
> Patch 1 and 2 are actual fixes and should be applied toghether. If
> the clock tree changes are applied only, master mode won't work
> anymore. With only the device tree changes applied, it probably
> will still work but the VF610_CLK_SAIx_DIV will be enabled twice.
> 
> Since Patch 3 also uses the fixed clock layout, it should be
> applied after the clock tree fix too...
> 
> Not sure through which tree these changes should go?
> 
> --
> Stefan
> 
>  drivers/clk/imx/clk-vf610.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> index bff45ea..42a7a23 100644
> --- a/drivers/clk/imx/clk-vf610.c
> +++ b/drivers/clk/imx/clk-vf610.c
> @@ -335,22 +335,22 @@ static void __init vf610_clocks_init(struct
> device_node *ccm_node)
>   clk[VF610_CLK_SAI0_SEL] = imx_clk_mux("sai0_sel", CCM_CSCMR1, 0, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI0_EN] = imx_clk_gate("sai0_en", "sai0_sel", 
> CCM_CSCDR1, 16);
>   clk[VF610_CLK_SAI0_DIV] = imx_clk_divider("sai0_div", "sai0_en",
> CCM_CSCDR1, 0, 4);
> - clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "sai0_div", CCM_CCGR0,
> CCM_CCGRx_CGn(15));
> + clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "ipg_bus", CCM_CCGR0,
> CCM_CCGRx_CGn(15));
>  
>   clk[VF610_CLK_SAI1_SEL] = imx_clk_mux("sai1_sel", CCM_CSCMR1, 2, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI1_EN] = imx_clk_gate("sai1_en", "sai1_sel", 
> CCM_CSCDR1, 17);
>   clk[VF610_CLK_SAI1_DIV] = imx_clk_divider("sai1_div", "sai1_en",
> CCM_CSCDR1, 4, 4);
> - clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "sai1_div", CCM_CCGR1,
> CCM_CCGRx_CGn(0));
> + clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "ipg_bus", CCM_CCGR1,
> CCM_CCGRx_CGn(0));
>  
>   clk[VF610_CLK_SAI2_SEL] = imx_clk_mux("sai2_sel", CCM_CSCMR1, 4, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI2_EN] = imx_clk_gate("sai2_en", "sai2_sel", 
> CCM_CSCDR1, 18);
>   clk[VF610_CLK_SAI2_DIV] = imx_clk_divider("sai2_div", "sai2_en",
> CCM_CSCDR1, 8, 4);
> - clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "sai2_div", CCM_CCGR1,
> CCM_CCGRx_CGn(1));
> + clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "ipg_bus", CCM_CCGR1,
> CCM_CCGRx_CGn(1));
>  
>   clk[VF610_CLK_SAI3_SEL] = imx_clk_mux("sai3_sel", CCM_CSCMR1, 6, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI3_EN] = imx_clk_gate("sai3_en", "sai3_sel", 
> CCM_CSCDR1, 19);
>   clk[VF610_CLK_SAI3_DIV] = imx_clk_divider("sai3_div", "sai3_en",
> CCM_CSCDR1, 12, 4);
> - clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "sai3_div", CCM_CCGR1,
> CCM_CCGRx_CGn(2));
> + clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "ipg_bus", CCM_CCGR1,
> CCM_CCGRx_CGn(2));
>  
>   clk[VF610_CLK_NFC_SEL] = imx_clk_mux("nfc_sel", CCM_CSCMR1, 12, 2,
> nfc_sels, 4);
>   clk[VF610_CLK_NFC_EN] = imx_clk_gate("nfc_en", "nfc_sel", CCM_CSCDR2, 
> 9);
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: vf610: fix clock definition for SAI2

2015-10-17 Thread Stefan Agner
So far, only the bus clock has been assigned, but in reality the
SAI IP has for clock inputs. The driver has been updated to
make use of the additional clock inputs by c3ecef21c3f2 ("ASoC:
fsl_sai: add sai master mode support"). Due to a bug in the
clock tree, the audio clock has been enabled none the less by
the specified bus clock (see "ARM: imx: clk-vf610: fix SAI
clock tree"), which made master mode even without the proper
clock assigned working.

This patch completes the clock definition for SAI2. On Vybrid,
only two MCLK out of the four options are available (the first
being the bus clock itself). See chapter 8.10.1.2.3 of the
Vybrid Reference manual ("SAI transmitter and receiver options
for MCLK selection"). Note: The audio clocks are only required
in master mode.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vfxxx.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 6865137..c2a4d1c 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -178,8 +178,10 @@
compatible = "fsl,vf610-sai";
reg = <0x40031000 0x1000>;
interrupts = <86 IRQ_TYPE_LEVEL_HIGH>;
-   clocks = <&clks VF610_CLK_SAI2>;
-   clock-names = "sai";
+   clocks = <&clks VF610_CLK_SAI2>,
+   <&clks VF610_CLK_SAI2_DIV>,
+   <&clks 0>, <&clks 0>;
+   clock-names = "bus", "mclk1", "mclk2", "mclk3";
dma-names = "tx", "rx";
dmas = <&edma0 0 21>,
<&edma0 0 20>;
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: imx: clk-vf610: fix SAI clock tree

2015-10-17 Thread Stefan Agner
The Synchronous Audio Interface (SAI) instances are clocked by
independent clocks: The bus clock and the audio clock (as shown in
Figure 51-1 in the Vybrid Reference Manual). The clock gates in
CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access
tests to the registers with/without gating those clocks have shown.
The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1,
followed by a clock divider (SAIx_DIV). Currently, the parent of
the bus clock gates has been assigned to SAIx_DIV, which is not
involved in the bus clock path for the SAI instances (see chapter
9.10.12, SAI clocking in the Vybrid Reference Manual).

Fix this by define the parent clock of VF610_CLK_SAIx to be the bus
clock.

If the driver needs the audio clock (when used in master mode), a
fixed device tree is required which assign the audio clock properly
to VF610_CLK_SAIx_DIV.

Signed-off-by: Stefan Agner 
---
Hi all,

Patch 1 and 2 are actual fixes and should be applied toghether. If
the clock tree changes are applied only, master mode won't work
anymore. With only the device tree changes applied, it probably
will still work but the VF610_CLK_SAIx_DIV will be enabled twice.

Since Patch 3 also uses the fixed clock layout, it should be
applied after the clock tree fix too...

Not sure through which tree these changes should go?

--
Stefan

 drivers/clk/imx/clk-vf610.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
index bff45ea..42a7a23 100644
--- a/drivers/clk/imx/clk-vf610.c
+++ b/drivers/clk/imx/clk-vf610.c
@@ -335,22 +335,22 @@ static void __init vf610_clocks_init(struct device_node 
*ccm_node)
clk[VF610_CLK_SAI0_SEL] = imx_clk_mux("sai0_sel", CCM_CSCMR1, 0, 2, 
sai_sels, 4);
clk[VF610_CLK_SAI0_EN] = imx_clk_gate("sai0_en", "sai0_sel", 
CCM_CSCDR1, 16);
clk[VF610_CLK_SAI0_DIV] = imx_clk_divider("sai0_div", "sai0_en", 
CCM_CSCDR1, 0, 4);
-   clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "sai0_div", CCM_CCGR0, 
CCM_CCGRx_CGn(15));
+   clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "ipg_bus", CCM_CCGR0, 
CCM_CCGRx_CGn(15));
 
clk[VF610_CLK_SAI1_SEL] = imx_clk_mux("sai1_sel", CCM_CSCMR1, 2, 2, 
sai_sels, 4);
clk[VF610_CLK_SAI1_EN] = imx_clk_gate("sai1_en", "sai1_sel", 
CCM_CSCDR1, 17);
clk[VF610_CLK_SAI1_DIV] = imx_clk_divider("sai1_div", "sai1_en", 
CCM_CSCDR1, 4, 4);
-   clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "sai1_div", CCM_CCGR1, 
CCM_CCGRx_CGn(0));
+   clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "ipg_bus", CCM_CCGR1, 
CCM_CCGRx_CGn(0));
 
clk[VF610_CLK_SAI2_SEL] = imx_clk_mux("sai2_sel", CCM_CSCMR1, 4, 2, 
sai_sels, 4);
clk[VF610_CLK_SAI2_EN] = imx_clk_gate("sai2_en", "sai2_sel", 
CCM_CSCDR1, 18);
clk[VF610_CLK_SAI2_DIV] = imx_clk_divider("sai2_div", "sai2_en", 
CCM_CSCDR1, 8, 4);
-   clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "sai2_div", CCM_CCGR1, 
CCM_CCGRx_CGn(1));
+   clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "ipg_bus", CCM_CCGR1, 
CCM_CCGRx_CGn(1));
 
clk[VF610_CLK_SAI3_SEL] = imx_clk_mux("sai3_sel", CCM_CSCMR1, 6, 2, 
sai_sels, 4);
clk[VF610_CLK_SAI3_EN] = imx_clk_gate("sai3_en", "sai3_sel", 
CCM_CSCDR1, 19);
clk[VF610_CLK_SAI3_DIV] = imx_clk_divider("sai3_div", "sai3_en", 
CCM_CSCDR1, 12, 4);
-   clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "sai3_div", CCM_CCGR1, 
CCM_CCGRx_CGn(2));
+   clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "ipg_bus", CCM_CCGR1, 
CCM_CCGRx_CGn(2));
 
clk[VF610_CLK_NFC_SEL] = imx_clk_mux("nfc_sel", CCM_CSCMR1, 12, 2, 
nfc_sels, 4);
clk[VF610_CLK_NFC_EN] = imx_clk_gate("nfc_en", "nfc_sel", CCM_CSCDR2, 
9);
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: vf610: add remaining SAI instaces

2015-10-17 Thread Stefan Agner
This adds the remaining SAI instances SAI0, SAI1 and SAI3. All
instances are very similar, except that the DMA channel of SAI3
is available on MUX1 (compared to MUX0 for SAI0-SAI2). Also,
SAI3 has a slightly different memory map due to a deeper FIFO,
however in practice the current driver works for SAI3 fine.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vfxxx.dtsi | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index c2a4d1c..b45bc81 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -174,6 +174,34 @@
status = "disabled";
};
 
+   sai0: sai@4002f000 {
+   compatible = "fsl,vf610-sai";
+   reg = <0x4002f000 0x1000>;
+   interrupts = <84 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_SAI0>,
+   <&clks VF610_CLK_SAI0_DIV>,
+   <&clks 0>, <&clks 0>;
+   clock-names = "bus", "mclk1", "mclk2", "mclk3";
+   dma-names = "tx", "rx";
+   dmas = <&edma0 0 17>,
+   <&edma0 0 16>;
+   status = "disabled";
+   };
+
+   sai1: sai@4003 {
+   compatible = "fsl,vf610-sai";
+   reg = <0x4003 0x1000>;
+   interrupts = <85 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_SAI1>,
+   <&clks VF610_CLK_SAI1_DIV>,
+   <&clks 0>, <&clks 0>;
+   clock-names = "bus", "mclk1", "mclk2", "mclk3";
+   dma-names = "tx", "rx";
+   dmas = <&edma0 0 19>,
+   <&edma0 0 18>;
+   status = "disabled";
+   };
+
sai2: sai@40031000 {
compatible = "fsl,vf610-sai";
reg = <0x40031000 0x1000>;
@@ -188,6 +216,20 @@
status = "disabled";
};
 
+   sai3: sai@40032000 {
+   compatible = "fsl,vf610-sai";
+   reg = <0x40032000 0x1000>;
+   interrupts = <87 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_SAI3>,
+   <&clks VF610_CLK_SAI3_DIV>,
+   <&clks 0>, <&clks 0>;
+   clock-names = "bus", "mclk1", "mclk2", "mclk3";
+   dma-names = "tx", "rx";
+   dmas = <&edma0 1 9>,
+   <&edma0 1 8>;
+   status = "disabled";
+   };
+
pit: pit@40037000 {
compatible = "fsl,vf610-pit";
reg = <0x40037000 0x1000>;
-- 
2.6.1

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


[PATCH] of/fdt: fix aliases with baudrate in earlycon

2015-10-10 Thread Stefan Agner
Many boards use an alias in the stdout-path specification along
with console options after a colon (e.g. serial0:115200n8). When
using earlycon, this specification currently does not work. While
fdt_path_offset supports alias resolution, it does not remove the
console options by itself. Use the fdt_path_offset_namelen variant
and provide the length of the alias to enable aliases with console
options in the stdout-path.

Signed-off-by: Stefan Agner 
---
Hi,

Stumbled upon this while testing 32-bit ARM earlycon support. It
seems that this once already came up on the list:
https://lkml.org/lkml/2015/3/13/562

--
Stefan


 drivers/of/fdt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 6e82bc42..9fc3568 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -813,8 +813,11 @@ static int __init early_init_dt_scan_chosen_serial(void)
if (!p || !l)
return -ENOENT;
 
+   /* Remove console options if present */
+   l = strchrnul(p, ':') - p;
+
/* Get the node specified by stdout-path */
-   offset = fdt_path_offset(fdt, p);
+   offset = fdt_path_offset_namelen(fdt, p, l);
if (offset < 0)
return -ENODEV;
 
-- 
2.6.1

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


[PATCH v13 1/2] ARM: dts: vf610twr: add NAND flash controller peripherial

2015-10-07 Thread Stefan Agner
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
Hi Shawn,

This are the rebased dt changes of the Vybrid MTD NAND driver
patchset. The driver part has recently been merged:
https://lkml.org/lkml/2015/9/2/678

The driver is lined up fo 4.4, I hope those changes make it into
4.4 as well.

Changes since v12:
- Rebased (and fixed merge conflict)
- Fix indent

 arch/arm/boot/dts/vf610-twr.dts | 47 +
 arch/arm/boot/dts/vfxxx.dtsi| 11 ++
 2 files changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..5438ee4 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,26 @@
};
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 6865137..6736bae 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -564,6 +564,17 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
+
i2c2: i2c@400e6000 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.6.1

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


[PATCH v13 2/2] ARM: dts: vf-colibri: enable NAND flash controller

2015-10-07 Thread Stefan Agner
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..e5949b9 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,26 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +176,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.6.1

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


Re: [PATCH v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-10-07 Thread Stefan Agner
Hi Brian,

On 2015-09-29 13:57, Brian Norris wrote:
> Pushed this patch to l2-mtd.git, as it looks pretty much good. Although,
> I'd like raw read support...
> 
> On Wed, Sep 02, 2015 at 06:06:34PM -0700, Stefan Agner wrote:
>> This adds hardware ECC support using the BCH encoder in the NFC IP.
>> The ECC encoder supports up to 32-bit correction by using 60 error
>> correction bytes. There is no sub-page ECC step, ECC is calculated
>> always accross the whole page (up to 2k pages).
>>
>> Limitations:
>> - HW ECC: Only 2K page with 64+ OOB.
>> - HW ECC: Only 24 and 32-bit error correction implemented.
>>
>> Raw writes have been tested using the generic nand_write_page_raw
>> implementation. However, raw reads are currently not possible
>> because the controller need to know whether we are going to use
>> the ECC mode already at NAND_CMD_READ0 command time. At this point
>> we do not have the information whether it is a raw read or a
>> regular read at driver level...
> 
> Hmm, can you get this in ecc.read_page_raw()?

Even just a read_page_raw implementation doesn't help. The controller
requires the ECC to be configured at command issue time, and the driver
issues the command in the cmdfunc callback. The function
nand_do_read_ops calls cmdfunc before ecc.read_page_raw...

I could just bail out in the NAND_CMD_READ0 case, and execute the
command from within the ecc.read_page_raw callback function. A bit
hacky, but that would work.

For that case, it would be nicer if cmdfunc somehow provides the
information that a raw read is requested, we would have that information
in nand_do_read_ops. However, that would need an extension of the
cmdfunc interface... Also, not sure how that should look like.

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


[PATCH v12 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-09-02 Thread Stefan Agner
This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
been tested using 8-bit and 16-bit NAND interface on the ARM based
Vybrid SoC VF500 and VF610 platform.
parameter page reading.

Limitations:
- Untested on MPC5125 and M54418.
- DMA and pipelining not used.
- 2K pages or less.
- No chip select, one NAND chip per controller.
- No hardware ECC.

Some paths have been hand-optimized and evaluated by measurements
made using mtd_speedtest.ko on a 100MB MTD partition.

Colibri VF50
eb write %   eb read %   page write  %   page read %
rel/opt 5175   115374560 11039
opt 5164 -0.21 11420 -1.01  4737 +3.88   10918 -1.10
none5113 -1.20 11352 -1.60  4490 -1.54   10865 -1.58

Colibri VF61
eb write %   eb read %   page write  %   page read %
rel/opt 5766   130965459 12846
opt 5883 +2.03 13064 -0.24  5561 +1.87   12802 -0.34
none5701 -1.13 12980 -0.89  5488 +0.53   12735 -0.86

rel = using readl_relaxed/writel_relaxed in optimized paths
opt = hand-optimized by combining multiple accesses into one read/write

The measurements have not been statistically verfied, hence use them
with care. The author came to the conclusion that using the relaxed
variants of readl/writel are not worth the additional code.

Signed-off-by: Bill Pringlemeir 
Tested-by: Albert ARIBAUD 
Signed-off-by: Stefan Agner 
---
 MAINTAINERS  |   6 +
 drivers/mtd/nand/Kconfig |   9 +
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 686 +++
 4 files changed, 702 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9567329..59975c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10835,6 +10835,12 @@ S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
 
+VF610 NAND DRIVER
+M: Stefan Agner 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/vf610_nfc.c
+
 VFAT/FAT/MSDOS FILESYSTEM
 M: OGAWA Hirofumi 
 S: Maintained
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3324281..9f9736c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -460,6 +460,15 @@ config MTD_NAND_MPC5121_NFC
  This enables the driver for the NAND flash controller on the
  MPC5121 SoC.
 
+config MTD_NAND_VF610_NFC
+   tristate "Support for Freescale NFC for VF610/MPC5125"
+   depends on (SOC_VF610 || COMPILE_TEST)
+   help
+ Enables support for NAND Flash Controller on some Freescale
+ processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
+ The driver supports a maximum 2k page size. The driver
+ currently does not support hardware ECC.
+
 config MTD_NAND_MXC
tristate "MXC NAND support"
depends on ARCH_MXC
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..a490af8 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES)   += 
socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)   += txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)  += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..0d76b3d1247
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,686 @@
+/*
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Jason ported to M54418TWR and MVFA5 (VF610).
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This 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.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA and pipelining not used.
+ * - 2K pages or less.
+ * - No chip select, one NAND chip per controller.
+ * - No hardware ECC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"vf610_nfc"
+
+/* Register Offs

[PATCH v12 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-09-02 Thread Stefan Agner
Signed-off-by: Bill Pringlemeir 
Acked-by: Shawn Guo 
Signed-off-by: Stefan Agner 
---
 .../devicetree/bindings/mtd/vf610-nfc.txt  | 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..6be4871
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,59 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc".
+- reg: address range of the NFC.
+- interrupts: interrupt of the NFC.
+- #address-cells: shall be set to 1. Encode the nand CS.
+- #size-cells : shall be set to 0.
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+
+Required children nodes:
+Children nodes represent the available nand chips. Currently the driver can
+only handle one NAND chip.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc-cs".
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+- nand-on-flash-bbt: see nand.txt
+
+Example:
+
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x400e 0x4000>;
+   interrupts = ;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+   };
-- 
2.5.1

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


[PATCH v12 5/5] ARM: dts: vf-colibri: enable NAND flash controller

2015-09-02 Thread Stefan Agner
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..e5949b9 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,26 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +176,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.5.1

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


[PATCH v12 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

2015-09-02 Thread Stefan Agner
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 47 +
 arch/arm/boot/dts/vfxxx.dtsi| 10 +
 2 files changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..64d1696 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,26 @@
};
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..17066a2 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,16 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
};
};
 };
-- 
2.5.1

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


[PATCH v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-09-02 Thread Stefan Agner
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages).

Limitations:
- HW ECC: Only 2K page with 64+ OOB.
- HW ECC: Only 24 and 32-bit error correction implemented.

Raw writes have been tested using the generic nand_write_page_raw
implementation. However, raw reads are currently not possible
because the controller need to know whether we are going to use
the ECC mode already at NAND_CMD_READ0 command time. At this point
we do not have the information whether it is a raw read or a
regular read at driver level...

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Kconfig |   6 +-
 drivers/mtd/nand/vf610_nfc.c | 203 ++-
 2 files changed, 205 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 9f9736c..ccd1158 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -466,8 +466,10 @@ config MTD_NAND_VF610_NFC
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
 
 config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 0d76b3d1247..4513b08 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,8 +19,8 @@
  * - Untested on MPC5125 and M54418.
  * - DMA and pipelining not used.
  * - 2K pages or less.
- * - No chip select, one NAND chip per controller.
- * - No hardware ECC.
+ * - HW ECC: Only 2K page with 64+ OOB.
+ * - HW ECC: Only 24 and 32-bit error correction implemented.
  */
 
 #include 
@@ -77,6 +77,8 @@
 
 /* NFC ECC mode define */
 #define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
 
 /*** Register Mask and bit definitions */
 
@@ -129,6 +131,18 @@
 #define CMD_DONE_CLEAR_BIT BIT(18)
 #define IDLE_CLEAR_BIT BIT(17)
 
+/*
+ * ECC status - seems to consume 8 bytes (double word). The documented
+ * status byte is located in the lowest byte of the second word (which is
+ * the 4th or 7th byte depending on endianness).
+ * Calculate an offset to store the ECC status at the end of the buffer.
+ */
+#define ECC_SRAM_ADDR  (PAGE_2K + OOB_MAX - 8)
+
+#define ECC_STATUS 0x4
+#define ECC_STATUS_MASK0x80
+#define ECC_STATUS_ERR_COUNT   0x3F
+
 enum vf610_nfc_alt_buf {
ALT_BUF_DATA = 0,
ALT_BUF_ID = 1,
@@ -152,10 +166,40 @@ struct vf610_nfc {
enum vf610_nfc_alt_buf alt_buf;
enum vf610_nfc_variant variant;
struct clk *clk;
+   bool use_hw_ecc;
+   u32 ecc_mode;
 };
 
 #define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
 
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+   .eccbytes = 45,
+   .eccpos = {19, 20, 21, 22, 23,
+  24, 25, 26, 27, 28, 29, 30, 31,
+  32, 33, 34, 35, 36, 37, 38, 39,
+  40, 41, 42, 43, 44, 45, 46, 47,
+  48, 49, 50, 51, 52, 53, 54, 55,
+  56, 57, 58, 59, 60, 61, 62, 63},
+   .oobfree = {
+   {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+   .eccbytes = 60,
+   .eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
+  12, 13, 14, 15, 16, 17, 18, 19,
+  20, 21, 22, 23, 24, 25, 26, 27,
+  28, 29, 30, 31, 32, 33, 34, 35,
+  36, 37, 38, 39, 40, 41, 42, 43,
+  44, 45, 46, 47, 48, 49, 50, 51,
+  52, 53, 54, 55, 56, 57, 58, 59,
+  60, 61, 62, 63 },
+   .oobfree = {
+   {.offset = 2,
+.length = 2} }
+};
+
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
return readl(nfc->regs + reg);
@@ -297,6 +341,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc, 
int column, int page)
ROW_ADDR_SHIFT, page);
 }
 
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+   vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+   CONFIG_ECC_MODE_MASK,
+   CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
 static inline void vf610_nfc_transfer_size(struct vf610_nfc *

[PATCH v12 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610

2015-09-02 Thread Stefan Agner
o 32 bit errors
- Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes
  which uses up to 60 bytes on 64 byte OOB
- Removed custom (downstream) BBT pattern since BBT table won't be
  compatible anyway (due to the change above)

Stefan Agner (5):
  mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
  mtd: nand: vf610_nfc: add hardware BCH-ECC support
  mtd: nand: vf610_nfc: add device tree bindings
  ARM: dts: vf610twr: add NAND flash controller peripherial
  ARM: dts: vf-colibri: enable NAND flash controller

 .../devicetree/bindings/mtd/vf610-nfc.txt  |  59 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/vf-colibri.dtsi  |  39 +
 arch/arm/boot/dts/vf610-twr.dts|  47 ++
 arch/arm/boot/dts/vfxxx.dtsi   |  10 +
 drivers/mtd/nand/Kconfig   |  11 +
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/vf610_nfc.c   | 885 +
 8 files changed, 1058 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

-- 
2.5.1

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


Re: [PATCH v11 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-09-01 Thread Stefan Agner
On 2015-08-27 17:34, Stefan Agner wrote:
> +static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t *dat,
> +  uint8_t *oob, int page)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> + u32 ecc_status_off = NFC_MAIN_AREA(0) + ECC_SRAM_ADDR + ECC_STATUS;
> + u8 ecc_status;
> + u8 ecc_count;
> + int flips;
> + int flips_threshold = nfc->chip.ecc.strength / 2;
> +
> + ecc_status = vf610_nfc_read(nfc, ecc_status_off) & 0xff;
> + ecc_count = ecc_status & ECC_STATUS_ERR_COUNT;
> +
> + if (!(ecc_status & ECC_STATUS_MASK))
> + return ecc_count;
> +
> + /* Read OOB without ECC unit enabled */
> + vf610_nfc_command(mtd, NAND_CMD_READOOB, 0, page);
> + vf610_nfc_read_buf(mtd, oob, mtd->oobsize);
> +
> + /*
> +  * On an erased page, bit count (including OOB) should be zero or
> +  * at least less then half of the ECC strength.
> +  */
> + flips = count_written_bits(dat, nfc->chip.ecc.size, flips_threshold);
> + flips += count_written_bits(oob, mtd->oobsize, flips_threshold);
> +
> + if (unlikely(flips > flips_threshold))
> + return -EINVAL;
> +
> + /* Erased page. */
> + memset(dat, 0xff, nfc->chip.ecc.size);
> + memset(oob, 0xff, mtd->oobsize);
> + return 0;

I guess I should return the amount of bitflips here. Will send out a v12
today.

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


[PATCH v11 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

2015-08-27 Thread Stefan Agner
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 47 +
 arch/arm/boot/dts/vfxxx.dtsi| 10 +
 2 files changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..64d1696 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,26 @@
};
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <24>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..17066a2 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,16 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
};
};
 };
-- 
2.5.0

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


[PATCH v11 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-08-27 Thread Stefan Agner
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages).

Limitations:
- HW ECC: Only 2K page with 64+ OOB.
- HW ECC: Only 24 and 32-bit error correction implemented.

Raw writes have been tested using the generic nand_write_page_raw
implementation. However, raw reads are currently not possible
because the controller need to know whether we are going to use
the ECC mode already at NAND_CMD_READ0 command time. At this point
we do not have the information whether it is a raw read or a
regular read at driver level...

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Kconfig |   6 +-
 drivers/mtd/nand/vf610_nfc.c | 204 ++-
 2 files changed, 206 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 9f9736c..ccd1158 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -466,8 +466,10 @@ config MTD_NAND_VF610_NFC
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
 
 config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index eba67dc..14f51c8 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,8 +19,8 @@
  * - Untested on MPC5125 and M54418.
  * - DMA and pipelining not used.
  * - 2K pages or less.
- * - No chip select, one NAND chip per controller.
- * - No hardware ECC.
+ * - HW ECC: Only 2K page with 64+ OOB.
+ * - HW ECC: Only 24 and 32-bit error correction implemented.
  */
 
 #include 
@@ -77,6 +77,8 @@
 
 /* NFC ECC mode define */
 #define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
 
 /*** Register Mask and bit definitions */
 
@@ -129,6 +131,18 @@
 #define CMD_DONE_CLEAR_BIT BIT(18)
 #define IDLE_CLEAR_BIT BIT(17)
 
+/*
+ * ECC status - seems to consume 8 bytes (double word). The documented
+ * status byte is located in the lowest byte of the second word (which is
+ * the 4th or 7th byte depending on endianness).
+ * Calculate an offset to store the ECC status at the end of the buffer.
+ */
+#define ECC_SRAM_ADDR  (PAGE_2K + OOB_MAX - 8)
+
+#define ECC_STATUS 0x4
+#define ECC_STATUS_MASK0x80
+#define ECC_STATUS_ERR_COUNT   0x3F
+
 enum vf610_nfc_alt_buf {
ALT_BUF_DATA = 0,
ALT_BUF_ID = 1,
@@ -152,10 +166,40 @@ struct vf610_nfc {
enum vf610_nfc_alt_buf alt_buf;
enum vf610_nfc_variant variant;
struct clk *clk;
+   bool use_hw_ecc;
+   u32 ecc_mode;
 };
 
 #define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
 
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+   .eccbytes = 45,
+   .eccpos = {19, 20, 21, 22, 23,
+  24, 25, 26, 27, 28, 29, 30, 31,
+  32, 33, 34, 35, 36, 37, 38, 39,
+  40, 41, 42, 43, 44, 45, 46, 47,
+  48, 49, 50, 51, 52, 53, 54, 55,
+  56, 57, 58, 59, 60, 61, 62, 63},
+   .oobfree = {
+   {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+   .eccbytes = 60,
+   .eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
+  12, 13, 14, 15, 16, 17, 18, 19,
+  20, 21, 22, 23, 24, 25, 26, 27,
+  28, 29, 30, 31, 32, 33, 34, 35,
+  36, 37, 38, 39, 40, 41, 42, 43,
+  44, 45, 46, 47, 48, 49, 50, 51,
+  52, 53, 54, 55, 56, 57, 58, 59,
+  60, 61, 62, 63 },
+   .oobfree = {
+   {.offset = 2,
+.length = 2} }
+};
+
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
return readl(nfc->regs + reg);
@@ -298,6 +342,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc, 
int column, int page)
ROW_ADDR_SHIFT, page);
 }
 
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+   vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+   CONFIG_ECC_MODE_MASK,
+   CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
 static inline void vf610_nfc_transfer_size(struct vf610_nfc *

[PATCH v11 5/5] ARM: dts: vf-colibri: enable NAND flash controller

2015-08-27 Thread Stefan Agner
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..e5949b9 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,26 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +176,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.5.0

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


[PATCH v11 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-08-27 Thread Stefan Agner
This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
been tested using 8-bit and 16-bit NAND interface on the ARM based
Vybrid SoC VF500 and VF610 platform.
parameter page reading.

Limitations:
- Untested on MPC5125 and M54418.
- DMA and pipelining not used.
- 2K pages or less.
- No chip select, one NAND chip per controller.
- No hardware ECC.

Some paths have been hand-optimized and evaluated by measurements
made using mtd_speedtest.ko on a 100MB MTD partition.

Colibri VF50
eb write %   eb read %   page write  %   page read %
rel/opt 5175   115374560 11039
opt 5164 -0.21 11420 -1.01  4737 +3.88   10918 -1.10
none5113 -1.20 11352 -1.60  4490 -1.54   10865 -1.58

Colibri VF61
eb write %   eb read %   page write  %   page read %
rel/opt 5766   130965459 12846
opt 5883 +2.03 13064 -0.24  5561 +1.87   12802 -0.34
none5701 -1.13 12980 -0.89  5488 +0.53   12735 -0.86

rel = using readl_relaxed/writel_relaxed in optimized paths
opt = hand-optimized by combining multiple accesses into one read/write

The measurements have not been statistically verfied, hence use them
with care. The author came to the conclusion that using the relaxed
variants of readl/writel are not worth the additional code.

Signed-off-by: Bill Pringlemeir 
Tested-by: Albert ARIBAUD 
Signed-off-by: Stefan Agner 
---
 MAINTAINERS  |   6 +
 drivers/mtd/nand/Kconfig |   9 +
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 690 +++
 4 files changed, 706 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9567329..59975c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10835,6 +10835,12 @@ S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
 
+VF610 NAND DRIVER
+M: Stefan Agner 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/vf610_nfc.c
+
 VFAT/FAT/MSDOS FILESYSTEM
 M: OGAWA Hirofumi 
 S: Maintained
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 3324281..9f9736c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -460,6 +460,15 @@ config MTD_NAND_MPC5121_NFC
  This enables the driver for the NAND flash controller on the
  MPC5121 SoC.
 
+config MTD_NAND_VF610_NFC
+   tristate "Support for Freescale NFC for VF610/MPC5125"
+   depends on (SOC_VF610 || COMPILE_TEST)
+   help
+ Enables support for NAND Flash Controller on some Freescale
+ processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
+ The driver supports a maximum 2k page size. The driver
+ currently does not support hardware ECC.
+
 config MTD_NAND_MXC
tristate "MXC NAND support"
depends on ARCH_MXC
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..a490af8 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES)   += 
socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)   += txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)  += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..eba67dc
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,690 @@
+/*
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Jason ported to M54418TWR and MVFA5 (VF610).
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This 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.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA and pipelining not used.
+ * - 2K pages or less.
+ * - No chip select, one NAND chip per controller.
+ * - No hardware ECC.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"vf610_nfc"
+
+/* Register Offs

[PATCH v11 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-08-27 Thread Stefan Agner
Signed-off-by: Bill Pringlemeir 
Acked-by: Shawn Guo 
Signed-off-by: Stefan Agner 
---
 .../devicetree/bindings/mtd/vf610-nfc.txt  | 59 ++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..6be4871
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,59 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc".
+- reg: address range of the NFC.
+- interrupts: interrupt of the NFC.
+- #address-cells: shall be set to 1. Encode the nand CS.
+- #size-cells : shall be set to 0.
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+
+Required children nodes:
+Children nodes represent the available nand chips. Currently the driver can
+only handle one NAND chip.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc-cs".
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+- nand-on-flash-bbt: see nand.txt
+
+Example:
+
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x400e 0x4000>;
+   interrupts = ;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+
+   nand@0 {
+   compatible = "fsl,vf610-nfc-nandcs";
+   reg = <0>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
+   };
-- 
2.5.0

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


[PATCH v11 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610

2015-08-27 Thread Stefan Agner
] mtd_speedtest: eraseblock write speed is 4718 KiB/s
[ 2344.053687] mtd_speedtest: testing eraseblock read speed
[ 2351.890573] mtd_speedtest: eraseblock read speed is 13059 KiB/s
[ 2352.315120] mtd_speedtest: testing page write speed
[ 2374.882015] mtd_speedtest: page write speed is 4533 KiB/s
[ 2374.887526] mtd_speedtest: testing page read speed
[ 2382.886572] mtd_speedtest: page read speed is 12791 KiB/s
[ 2383.290314] mtd_speedtest: testing 2 page write speed
[ 2405.362236] mtd_speedtest: 2 page write speed is 4634 KiB/s
[ 2405.367925] mtd_speedtest: testing 2 page read speed
[ 2413.299551] mtd_speedtest: 2 page read speed is 12901 KiB/s
[ 2413.305228] mtd_speedtest: Testing erase speed
[ 2413.707595] mtd_speedtest: erase speed is 257612 KiB/s
[ 2413.712796] mtd_speedtest: Testing 2x multi-block erase speed
[ 2414.110127] mtd_speedtest: 2x multi-block erase speed is 260897 KiB/s
[ 2414.116656] mtd_speedtest: Testing 4x multi-block erase speed
[ 2414.510316] mtd_speedtest: 4x multi-block erase speed is 264268 KiB/s
[ 2414.516838] mtd_speedtest: Testing 8x multi-block erase speed
[ 2414.908075] mtd_speedtest: 8x multi-block erase speed is 265641 KiB/s
[ 2414.914607] mtd_speedtest: Testing 16x multi-block erase speed
[ 2415.306958] mtd_speedtest: 16x multi-block erase speed is 264268 KiB/s
[ 2415.313586] mtd_speedtest: Testing 32x multi-block erase speed
[ 2415.702660] mtd_speedtest: 32x multi-block erase speed is 267028 KiB/s
[ 2415.709270] mtd_speedtest: Testing 64x multi-block erase speed
[ 2416.098225] mtd_speedtest: 64x multi-block erase speed is 266333 KiB/s
[ 2416.104833] mtd_speedtest: finished
[ 2416.108379] =====

Stefan Agner (5):
  mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
  mtd: nand: vf610_nfc: add hardware BCH-ECC support
  mtd: nand: vf610_nfc: add device tree bindings
  ARM: dts: vf610twr: add NAND flash controller peripherial
  ARM: dts: vf-colibri: enable NAND flash controller

 .../devicetree/bindings/mtd/vf610-nfc.txt  |  59 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/vf-colibri.dtsi  |  39 +
 arch/arm/boot/dts/vf610-twr.dts|  47 ++
 arch/arm/boot/dts/vfxxx.dtsi   |  10 +
 drivers/mtd/nand/Kconfig   |  11 +
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/vf610_nfc.c   | 890 +
 8 files changed, 1063 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

-- 
2.5.0

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


Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-08-27 Thread Stefan Agner
On 2015-08-27 09:34, Brian Norris wrote:
> On Wed, Aug 26, 2015 at 06:02:31PM -0700, Stefan Agner wrote:
>> On 2015-08-25 13:16, Brian Norris wrote:
>> > On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
>> >> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
>> >> new file mode 100644
>> >> index 000..5c8dfe8
>> >> --- /dev/null
>> >> +++ b/drivers/mtd/nand/vf610_nfc.c
>> >> @@ -0,0 +1,645 @@
>> >
>> > ...
>> >
>> >> +/*
>> >> + * This function supports Vybrid only (MPC5125 would have full RB and 
>> >> four CS)
>> >> + */
>> >> +static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
>> >> +{
>> >> +#ifdef CONFIG_SOC_VF610
>> >
>> > Why the #ifdef? I don't see anything compile-time specific to SOC_VF610.
>> >
>> > If this is trying to handle the comment above ("This function supports
>> > Vybrid only (MPC5125 would have full RB and four CS)") then that's the
>> > wrong way of doing it, as you need to support multiplatform kernels.
>> > You'll need to have a way to differentiate the different platform
>> > support at runtime, not compile time.
>>
>> Yes it is trying to handle the comment above. Well, the other two
>> platforms I am aware of are also different architectures... (PowerPC and
>> ColdFire). I think we won't have a multi-architecture kernel anytime
>> soon,
> 
> Ha, right. Sorry, I don't really know this particular IP.
> 
>> hence I think removing the code at compile time is the right thing
>> todo.
> 
> I don't believe that conclusion follows though.
> 
>> However, probably CONFIG_SOC_VF610 is the wrong symbol then, I could
>> just use CONFIG_ARM and add a comment that this might be different on
>> another other ARM SoC than VF610.
>>
>> Just checked CodingStyle, and I see that IS_ENABLED is the preferred way
>> for conditional compiling.
>>
>> So my suggestion:
>>
>> static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
>> {
>>  struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>>  u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
>>
>>  if (!IS_ENABLED(CONFIG_ARM))
>>  return;
>>
>>  /*
>>   * This code is only tested on the ARM platform VF610
>>   * PowerPC based MPC5125 would have full RB and four CS
>>   */
>> 
>>
>> With that the compiler should be able to remove this (currently) ARM
>> VF610 specific code on the other supported architectures...
>>
>> What do you think?
> 
> The code structure isn't bad, and yes, IS_ENABLED() would be preferable,
> as it removes some of the problems with #ifdef, but I still don't think
> the processor architecture has much to do with the version of the IP.

Well yes, the processor architecture has probably not much to do with
the IP version.

However, that particular problem, the wiring up of the CS/RB signals, is
probably more SoC (as a whole) specific, and how that is done might have
some relation which architecture is in use...

I do not have a strong opinion on this, so we might as well go with the
run-time distinction using compatible. If there are different IP
variants within one architecture, we anyway would need to do that.

> The canonical way of distiguishing per-IP revisions is to key on the
> compatible property. So you'd have some kind of enum, which would
> currently only have an entry for VF610. i.e.:
> 
>   /* MPC5125 not yet supported */
>   if (nfc->revision != NAND_VFC610)
>   return;
> 

Ok, just checked, I can use the data field of the of table to assign
specific data to a compatible string, similar to how pxa3xx_nand.c does
it.

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


Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-08-26 Thread Stefan Agner
On 2015-08-25 13:34, Brian Norris wrote:
> One more thing...
> 
> On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
>> --- /dev/null
>> +++ b/drivers/mtd/nand/vf610_nfc.c
>> @@ -0,0 +1,645 @@
> ...
>> +struct vf610_nfc {
>> +struct mtd_info mtd;
>> +struct nand_chip chip;
>> +struct device *dev;
>> +void __iomem *regs;
>> +struct completion cmd_done;
>> +uint buf_offset;
>> +int page_sz;
> 
> AFAICT (even with the 2nd patch), you never really use this field. You
> just set it/increment it, but don't use it for anything. Kill it?

It is used in the write path, I think I meant to use it for subpage
writes, when I thought it would just mean to transfer only parts of the
page to the controller.

However, as the subpage discussion basically concluded in not using it
for now on this controller, we can as well transfer the complete page
(page_sz). Or is there another case in which vf610_nfc_write_buf could
be called with less than page_sz?

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


Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-08-26 Thread Stefan Agner
On 2015-08-25 13:16, Brian Norris wrote:
> A few more comments.
> 
> On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
>> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
>> new file mode 100644
>> index 000..5c8dfe8
>> --- /dev/null
>> +++ b/drivers/mtd/nand/vf610_nfc.c
>> @@ -0,0 +1,645 @@
> 
> ...
> 
>> +/*
>> + * This function supports Vybrid only (MPC5125 would have full RB and four 
>> CS)
>> + */
>> +static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
>> +{
>> +#ifdef CONFIG_SOC_VF610
> 
> Why the #ifdef? I don't see anything compile-time specific to SOC_VF610.
> 
> If this is trying to handle the comment above ("This function supports
> Vybrid only (MPC5125 would have full RB and four CS)") then that's the
> wrong way of doing it, as you need to support multiplatform kernels.
> You'll need to have a way to differentiate the different platform
> support at runtime, not compile time.

Yes it is trying to handle the comment above. Well, the other two
platforms I am aware of are also different architectures... (PowerPC and
ColdFire). I think we won't have a multi-architecture kernel anytime
soon, hence I think removing the code at compile time is the right thing
todo.

However, probably CONFIG_SOC_VF610 is the wrong symbol then, I could
just use CONFIG_ARM and add a comment that this might be different on
another other ARM SoC than VF610.

Just checked CodingStyle, and I see that IS_ENABLED is the preferred way
for conditional compiling.

So my suggestion:

static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
{
struct vf610_nfc *nfc = mtd_to_nfc(mtd);
u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);

if (!IS_ENABLED(CONFIG_ARM))
return;

/*
 * This code is only tested on the ARM platform VF610
 * PowerPC based MPC5125 would have full RB and four CS
 */


With that the compiler should be able to remove this (currently) ARM
VF610 specific code on the other supported architectures...

What do you think?


> 
>> +struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>> +u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
>> +
>> +tmp &= ~(ROW_ADDR_CHIP_SEL_RB_MASK | ROW_ADDR_CHIP_SEL_MASK);
>> +tmp |= 1 << ROW_ADDR_CHIP_SEL_RB_SHIFT;
>> +
>> +if (chip == 0)
>> +tmp |= 1 << ROW_ADDR_CHIP_SEL_SHIFT;
>> +else if (chip == 1)
>> +tmp |= 2 << ROW_ADDR_CHIP_SEL_SHIFT;
> 
>   else ... ?
> 
> Maybe you can write this as a formulaic pattern (e.g.:
> 
>   tmp |= (chip + 1) << ROW_ADDR_CHIP_SEL_SHIFT;
> 
> ) and just do the "max # of chips" checks on a per-platform basis in the
> probe(). Then I'm guessing this same function can apply to both
> platforms. (I'm not looking at HW datasheets for this, BTW, just
> guessing based on the context here.)

It seems that MCP5125 is different than VF610. MCP5125 has 4 chip
selects and 4 R/B signals, whereas VF610 has only 2 chip selects and
just 1 R/B signals...

> But wait...I see that you call nand_scan_ident() with a max of 1 chip.
> So you won't ever see the chip > 0 case, right?
> 
> So does this driver support multiple flash attached or not? Looks like
> you're assuming you'll only be using chip-select 0. (This is fine for
> now, but at least your code should acknowledge this. Perhaps a comment
> at the top under "limitations.")
> 

Ok, will add that information under limitations.


>> +
>> +vf610_nfc_write(nfc, NFC_ROW_ADDR, tmp);
>> +#endif
>> +}
> 
> ...
> 
>> +static int vf610_nfc_probe(struct platform_device *pdev)
>> +{
> 
> ...
> 
>> +/* first scan to find the device and get the page size */
>> +if (nand_scan_ident(mtd, 1, NULL)) {
>> +err = -ENXIO;
>> +goto error;
>> +}

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


Re: [PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-08-26 Thread Stefan Agner
On 2015-08-26 08:39, Boris Brezillon wrote:
> Hi Bill,
> 
> On Wed, 26 Aug 2015 11:26:36 -0400
> Bill Pringlemeir  wrote:
> 
>> On 25 Aug 2015, computersforpe...@gmail.com wrote:
>>
>> > Sorry, I realized a potential issue here.
>>
>> > On Mon, Aug 03, 2015 at 11:27:28AM +0200, Stefan Agner wrote:
>> >> Signed-off-by: Bill Pringlemeir 
>> >> Acked-by: Shawn Guo 
>> >> Reviewed-by: Brian Norris 
>> >> Signed-off-by: Stefan Agner 
>> >> ---
>> >> .../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++
>> >> 1 file changed, 45 insertions(+) create mode 100644
>> >> Documentation/devicetree/bindings/mtd/vf610-nfc.txt
>>
>> >> diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
>> >> b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
>> >> new file mode 100644
>> >> index 000..cae5f25
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
>> >>>> -0,0 +1,45 @@
>> >> +- nand-bus-width: see nand.txt
>> >> +- nand-ecc-mode: see nand.txt
>> >> +- nand-on-flash-bbt: see nand.txt
>>
>> > Stumbling across the "multi-CS" questions on the driver reminds me: it
>> > typically makes sense to define new NAND bindings using separate NAND
>> > *controller* and *flash* device nodes. The above 3 properties, at
>> > least, would apply on a per-flash basis, not per-controller
>> > typically. See sunxi-nand, for instance:
>>
>> > http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
>>
>> > brcmnand had a similar pattern:
>>
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>>
>> > (Perhaps it's time we standardized this a little more formally...)
>>
>> These would apply per chip, but the controller has to be configured to
>> support each and every one.  Every time an operation was performed, we
>> would have to check the chip type and reconfigure the controller.
>> Currently, the driver does not support this and it would add a lot of
>> overhead in some cases unless a register cache was used.
>>
>> Is the flexibility of using a system with combined 8/16bit devices
>> really worth all the overhead?  Isn't it sort of brain dead hardware not
>> to make all of the chips similar?  Why would everyone have to pay for
>> such a crazy setup?
>>
>> To separate it would at least be a lie versus the code in the current
>> form.  As well, there are only a few SOC which support multiple chip
>> selects.  The 'multi-CS' register bits of this controller varies between
>> PowerPC, 68K/Coldfire and ARM platforms.

The DT can be a lie versus the code. The DT should reflect how the
hardware is wired, afaik, if we take shortcuts in the driver code, that
is fine. If we don't support a certain configuration right now (e.g.
second NAND chip), the driver can just return an appropriate error code.
>>
>> I looked briefly at the brcmnand.c  and it seems that it is not
>> supporting different ECC per chip even though the nodes are broken out
>> this way.  In fact, if some raw functions are called, I think it will
>> put it in ECC mode even if it wasn't before?  Well, I agree that this
>> would be good generically, I think it puts a lot of effort in the
>> drivers for not so much payoff?
> 
> Hm, the sunxi driver supports it, and it does not add such a big
> overhead...
> The only thing you have to do is cache a bunch of register values
> per-chip and restore/apply them when the chip is selected
> (in your ->select_chip() implementation).
> 
> Anyway, even if the suggested DT representation is a lie in regards to
> your implementation, it's actually pretty accurate from an hardware
> POV, and this is exactly what DT is supposed to represent.

I agree with both of you. I don't see much value implementing multi-NAND
chip support, especially with different configurations, at the moment. I
am not aware of any hardware making use of that now.

I will update the driver to parse a NAND sub node and get the ECC
properties from the per flash configuration. However, I won't add chip
select or multi-NAND support right now...

Any objection?

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


Re: [PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-08-26 Thread Stefan Agner
On 2015-08-25 12:54, Brian Norris wrote:
> On Mon, Aug 03, 2015 at 11:28:43AM +0200, Stefan Agner wrote:
>> On 2015-08-03 11:27, Stefan Agner wrote:
>> 
>> > +static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t 
>> > *dat,
>> > +   uint8_t *oob, int oob_loaded)
>> > +{
>> > +  struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>> > +  u8 ecc_status;
>> > +  u8 ecc_count;
>> > +  int flip;
>> > +
>> > +  ecc_status = __raw_readb(nfc->regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
> 
> Why __raw_readb()? That's not normally encourage, and it has issues with
> endianness. It looks like maybe this is actulaly a 32-bit register, and
> you're having trouble when trying to do bytewise access? I see this
> earlier:
> 
> /*
>  * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
>  * and +7 for big-endian SoCs.
>  */
> #ifdef __LITTLE_ENDIAN
> #define ECC_OFFSET  4
> #else
> #define ECC_OFFSET  7
> #endif
> 
> So maybe you really just want:
> 
> #define ECC_OFFSET4
> ...
>   ecc_status = vf610_nfc_read(ECC_SRAM_ADDR * 8 + ECC_OFFSET) & 0xff;
> 
> ?
> 

Agreed, much cleaner.

>> > +  ecc_count = ecc_status & ECC_ERR_COUNT;
>> > +
>> > +  if (!(ecc_status & ECC_STATUS_MASK))
>> > +  return ecc_count;
>> > +
>> > +  if (!oob_loaded)
>> > +  vf610_nfc_read_buf(mtd, oob, mtd->oobsize);
>> > +
>> > +  /*
>> > +   * On an erased page, bit count (including OOB) should be zero or
>> > +   * at least less then half of the ECC strength.
>> > +   */
>> > +  flip = count_written_bits(dat, nfc->chip.ecc.size, ecc_count);
> 
> Another side note: why are you using ecc_count as a max threshold? AIUI,
> an ECC algorithm doesn't really report useful error count information if
> it's above the correction limit. So wouldn't we be looking to count up
> to our SW threshold? i.e., ecc.strength / 2, or similar? Similar
> comments below.
> 

Initially, that was the only threshold below, hence it made sense. But I
agree, we should count up to the threshold used below...

>> > +  flip += count_written_bits(oob, mtd->oobsize - nfc->chip.ecc.bytes,
>> > + ecc_count);
>>
>> With ECC the controller seems to clear the ECC bytes in SRAM buffer.
>> This is a dump of 64 Bit OOB with the 32-error ECC mode which requires
>> 60 bytes of OOB for ECC:
>>
>> [   22.190273] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> Hmm, that's not really good. The point is that we need to make sure that
> everything that could have been programmed (including the ECC area) was
> not actually programmed. But your ECC controller is not, contrary to
> MTD's expectations, dumping raw uncorrected data here.
> 
>> [   22.209698] vf610_nfc_correct_data, flips 1
>>
>> Not sure if this is acceptable, but I now only count the bits in the
>> non-ECC area of the OOB.
> 
> That's not the intention of my suggestion. You're still missing out on a
> class of patterns that might look close to all 0xff but are not
> actually.
> 
> If the HW ECC really doesn't give you valid data+OOB at this point, then
> you might have to re-read with ECC disabled. Of course, that's got a
> performance cost...

Yes I can do that. Not sure yet how it will look like exactly, maybe I
only need to reread the OOB area and (re-)use the main data part since
those arrive uncorrected in the error case.

> 
> Or perhaps Boris has a better suggestion? He's been surveying other NAND
> drivers that need to do similar things, and he's working on providing
> some support code for common design patterns.
> 
>> Btw, if the ECC check fails, the controller seems kind of count the
>> amount of bitflips. It works for most devices reliable, but we had
>> devices for which that number was not accurate, see:
>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/357439
> 
> I'm a little confused there. Why would you be expecting to get a count
> of bitflips, when the ECC engine can't correct all errors? How is it
> supposed to know what the "right" data is if the bit errors are beyond
> the correction strength?

When printing the ECC error count on ECC fail when reading an erased
NAND flash, the numbers of bit flips (stuck at zero) seem to widely
correlate with the 

Re: [PATCH v4 1/3] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

2015-08-22 Thread Stefan Agner
On 2015-08-21 06:26, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  4 +++
>  arch/arm/boot/dts/vf500-colibri.dtsi| 47 
> +
>  2 files changed, 51 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..14c0b00 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,7 @@
>   model = "Toradex Colibri VF50 on Colibri Evaluation Board";
>   compatible = "toradex,vf500-colibri_vf50-on-eval",
> "toradex,vf500-colibri_vf50", "fsl,vf500";
>  };
> +
> +&touchscreen {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..84f091d 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,51 @@
>   memory {
>   reg = <0x8000 0x800>;
>   };
> +
> + touchscreen: vf50-touchscreen {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = <&adc1 0>,<&adc0 0>,
> + <&adc0 1>,<&adc1 2>;
> + xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <&pinctrl_touchctrl_idle>;
> + pinctrl-1 = <&pinctrl_touchctrl_default>;
> + pinctrl-2 = <&pinctrl_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;

Since this is a touch screen related property, we even would want to
have that in the board specific device-tree (vf500-colibri-eval-v3.dts).


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


Re: [PATCH v4 3/3] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-08-22 Thread Stefan Agner
Hi Sanchayan,

On 2015-08-21 06:26, Sanchayan Maity wrote:
> +static int vf50_ts_probe(struct platform_device *pdev)
> +{
> + struct input_dev *input;
> + struct iio_channel *channels;
> + struct device *dev = &pdev->dev;
> + struct vf50_touch_device *touchdev;
> + int error;
> +
> + channels = iio_channel_get_all(dev);
> + if (IS_ERR(channels))
> + return PTR_ERR(channels);

Hm, we expect here that four channels are returned, however a faulty
device tree could contain less. Access to the fourth channel above would
lead to a bug.

Can you check the amount of channels returned? The returned list is
explicitly terminated with a null entry, you can rely on that. Something
similar to hwmon should do the job.
http://lxr.free-electrons.com/source/drivers/hwmon/iio_hwmon.c#L86


Otherwise, Acked-by: Stefan Agner 

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


Re: [PATCH v4 2/3] input: Add DT binding documentation for Colibri VF50 touchscreen

2015-08-22 Thread Stefan Agner
On 2015-08-21 06:26, Sanchayan Maity wrote:
> This adds device tree binding documentation for the Colibri VF50
> touchscreen driver.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  .../bindings/input/touchscreen/colibri-vf50-ts.txt | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> 
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> new file mode 100644
> index 000..e615aa9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt
> @@ -0,0 +1,36 @@
> +* Toradex Colibri VF50 Touchscreen driver
> +
> +Required Properties:
> +- compatible must be toradex,vf50-touchscreen
> +- io-channels: adc channels being used by the Colibri VF50 module
> +- xp-gpios: FET gate driver for input of X+
> +- xm-gpios: FET gate driver for input of X-
> +- yp-gpios: FET gate driver for input of Y+
> +- ym-gpios: FET gate driver for input of Y-
> +- interrupt-parent: phandle for the interrupt controller
> +- interrupts: pen irq interrupt for touch detection

I like the use of the interrupt interface for the touch detection pin.
Maybe you can mention here that this is (typically) a GPIO...

> +- pinctrl-names: "idle", "default", "gpios"
> +- pinctrl-0: pinctrl node for idle state gpio pinmux
> +- pinctrl-1: pinctrl node for touch detection state pinmux

"touch detection" for default is rather confusing or even wrong. The
Idle state is used for pen/touch detection, default is used for X/Y and
Pressure measurement (maybe better described as touch measurement).

> +- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
> +- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y values
> +
> +Example:
> +
> + touchctrl: vf50_touchctrl {
> + compatible = "toradex,vf50-touchscreen";
> + io-channels = <&adc1 0>,<&adc0 0>,
> + <&adc0 1>,<&adc1 2>;
> + xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <&pinctrl_touchctrl_idle>;
> + pinctrl-1 = <&pinctrl_touchctrl_default>;
> + pinctrl-2 = <&pinctrl_touchctrl_gpios>;
> + vf50-ts-min-pressure = <200>;
> + status = "disabled";
> + };

Otherwise I agree with 1 and 2:

Acked-by: Stefan Agner 

--
Stefan

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


Re: [PATCH v5 2/2] ARM: dts: add property for maximum ADC clock frequencies

2015-08-03 Thread Stefan Agner
Hi Shawn,

I guess this will go through your tree? Haven't seen it appear on imx/dt
so far...

--
Stefan

On 2015-06-07 18:56, Jonathan Cameron wrote:
> On 27/05/15 13:47, Stefan Agner wrote:
>> The ADC clock frequency is limited depending on modes used. Add
>> device tree property which allow to set the mode used and the
>> maximum frequency ratings for the instance. These allows to
>> set the ADC clock to a frequency which is within specification
>> according to the actual mode used.
>>
>> Acked-by: Fugang Duan 
>> Signed-off-by: Stefan Agner 
> I'm happy to take this via IIO if people want me to, otherwise give
> it's connection to the previous patch that I just applied,
> 
> Acked-by: Jonathan Cameron 
> 
>> ---
>>  arch/arm/boot/dts/vfxxx.dtsi | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
>> index a29c7ce..c6609bd 100644
>> --- a/arch/arm/boot/dts/vfxxx.dtsi
>> +++ b/arch/arm/boot/dts/vfxxx.dtsi
>> @@ -189,6 +189,8 @@
>>  clocks = <&clks VF610_CLK_ADC0>;
>>  clock-names = "adc";
>>  status = "disabled";
>> +fsl,adck-max-frequency = <3000>, <4000>,
>> +<2000>;
>>  };
>>
>>  wdoga5: wdog@4003e000 {
>> @@ -387,6 +389,8 @@
>>  clocks = <&clks VF610_CLK_ADC1>;
>>  clock-names = "adc";
>>  status = "disabled";
>> +fsl,adck-max-frequency = <3000>, <4000>,
>> +<2000>;
>>  };
>>
>>  esdhc1: esdhc@400b2000 {
>>

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


Re: [PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-08-03 Thread Stefan Agner
Hi Brian,

On 2015-08-03 11:27, Stefan Agner wrote:

> +static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t *dat,
> +  uint8_t *oob, int oob_loaded)
> +{
> + struct vf610_nfc *nfc = mtd_to_nfc(mtd);
> + u8 ecc_status;
> + u8 ecc_count;
> + int flip;
> +
> + ecc_status = __raw_readb(nfc->regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
> + ecc_count = ecc_status & ECC_ERR_COUNT;
> +
> + if (!(ecc_status & ECC_STATUS_MASK))
> + return ecc_count;
> +
> + if (!oob_loaded)
> + vf610_nfc_read_buf(mtd, oob, mtd->oobsize);
> +
> + /*
> +  * On an erased page, bit count (including OOB) should be zero or
> +  * at least less then half of the ECC strength.
> +  */
> + flip = count_written_bits(dat, nfc->chip.ecc.size, ecc_count);
> + flip += count_written_bits(oob, mtd->oobsize - nfc->chip.ecc.bytes,
> +ecc_count);

With ECC the controller seems to clear the ECC bytes in SRAM buffer.
This is a dump of 64 Bit OOB with the 32-error ECC mode which requires
60 bytes of OOB for ECC:

[   22.190273] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   22.209698] vf610_nfc_correct_data, flips 1

Not sure if this is acceptable, but I now only count the bits in the
non-ECC area of the OOB.

Btw, if the ECC check fails, the controller seems kind of count the
amount of bitflips. It works for most devices reliable, but we had
devices for which that number was not accurate, see:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/357439

--
Stefan

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


[PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-08-03 Thread Stefan Agner
This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
been tested on 8-bit and 16-bit NAND interface and supports ONFI
parameter page reading.

Limitations:
- DMA and pipelining not used
- Pages larger than 2k are not supported
- No hardware ECC

The driver has only been tested on Vybrid SoC VF610 and VF500.

Some paths have been hand-optimized and evaluated by measurements
made using mtd_speedtest.ko on a 100MB MTD partition.

Colibri VF50
eb write %   eb read %   page write  %   page read %
rel/opt 5175   115374560 11039
opt 5164 -0.21 11420 -1.01  4737 +3.88   10918 -1.10
none5113 -1.20 11352 -1.60  4490 -1.54   10865 -1.58

Colibri VF61
eb write %   eb read %   page write  %   page read %
rel/opt 5766   130965459 12846
opt 5883 +2.03 13064 -0.24  5561 +1.87   12802 -0.34
none5701 -1.13 12980 -0.89  5488 +0.53   12735 -0.86

rel = using readl_relaxed/writel_relaxed in optimized paths
opt = hand-optimized by combining multiple accesses into one read/write

The measurements have not been statistically verfied, hence use them
with care. The author came to the conclusion that using the relaxed
variants of readl/writel are not worth the additional code.

Signed-off-by: Bill Pringlemeir 
Tested-by: Albert ARIBAUD 
Signed-off-by: Stefan Agner 
---
 MAINTAINERS  |   6 +
 drivers/mtd/nand/Kconfig |   9 +
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 645 +++
 4 files changed, 661 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9567329..59975c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10835,6 +10835,12 @@ S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
 
+VF610 NAND DRIVER
+M: Stefan Agner 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/vf610_nfc.c
+
 VFAT/FAT/MSDOS FILESYSTEM
 M: OGAWA Hirofumi 
 S: Maintained
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5b2806a..8550b14 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -463,6 +463,15 @@ config MTD_NAND_MPC5121_NFC
  This enables the driver for the NAND flash controller on the
  MPC5121 SoC.
 
+config MTD_NAND_VF610_NFC
+   tristate "Support for Freescale NFC for VF610/MPC5125"
+   depends on (SOC_VF610 || COMPILE_TEST)
+   help
+ Enables support for NAND Flash Controller on some Freescale
+ processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
+ The driver supports a maximum 2k page size. The driver
+ currently does not support hardware ECC.
+
 config MTD_NAND_MXC
tristate "MXC NAND support"
depends on ARCH_MXC
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..a490af8 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES)   += 
socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)   += txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)  += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..5c8dfe8
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,645 @@
+/*
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Jason ported to M54418TWR and MVFA5 (VF610).
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This 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.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA not used.
+ * - 2K pages or less.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"vf610_nfc"
+
+/* Register Offsets */
+#define NFC_FLASH_CMD1 0x3F00
+#define NFC_FLASH_CMD2 0x3F04
+#define NFC_COL_ADDR 

[PATCH v10 5/5] ARM: dts: vf-colibri: enable NAND flash controller

2015-08-03 Thread Stefan Agner
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..ab2e74b 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,19 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <32>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +169,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.5.0

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


[PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-08-03 Thread Stefan Agner
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages). Raw writes writes
are possible through the common nand_write_page_raw implementation,
however raw reads are not possible since the hardware ECC mode need
to be enabled at command time.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Kconfig |   6 +-
 drivers/mtd/nand/vf610_nfc.c | 206 ++-
 2 files changed, 209 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8550b14..e05f53c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -469,8 +469,10 @@ config MTD_NAND_VF610_NFC
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
 
 config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 5c8dfe8..247f06a 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,6 +19,8 @@
  * - Untested on MPC5125 and M54418.
  * - DMA not used.
  * - 2K pages or less.
+ * - Only 2K page w. 64+ OOB and hardware ECC.
+ * - Raw page reads not implemented when using ECC.
  */
 
 #include 
@@ -73,6 +75,8 @@
 
 /* NFC ECC mode define */
 #define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
 
 /*** Register Mask and bit definitions */
 
@@ -125,6 +129,21 @@
 #define CMD_DONE_CLEAR_BIT BIT(18)
 #define IDLE_CLEAR_BIT BIT(17)
 
+/* ECC status placed at end of buffers. */
+#define ECC_SRAM_ADDR  ((PAGE_2K + 256 - 8) >> 3)
+#define ECC_STATUS_MASK0x80
+#define ECC_ERR_COUNT  0x3F
+
+/*
+ * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
+ * and +7 for big-endian SoCs.
+ */
+#ifdef __LITTLE_ENDIAN
+#define ECC_OFFSET 4
+#else
+#define ECC_OFFSET 7
+#endif
+
 struct vf610_nfc {
struct mtd_info mtd;
struct nand_chip chip;
@@ -139,10 +158,40 @@ struct vf610_nfc {
 #define ALT_BUF_STAT 2
 #define ALT_BUF_ONFI 3
struct clk *clk;
+   bool use_hw_ecc;
+   u32 ecc_mode;
 };
 
 #define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
 
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+   .eccbytes = 45,
+   .eccpos = {19, 20, 21, 22, 23,
+  24, 25, 26, 27, 28, 29, 30, 31,
+  32, 33, 34, 35, 36, 37, 38, 39,
+  40, 41, 42, 43, 44, 45, 46, 47,
+  48, 49, 50, 51, 52, 53, 54, 55,
+  56, 57, 58, 59, 60, 61, 62, 63},
+   .oobfree = {
+   {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+   .eccbytes = 60,
+   .eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
+  12, 13, 14, 15, 16, 17, 18, 19,
+  20, 21, 22, 23, 24, 25, 26, 27,
+  28, 29, 30, 31, 32, 33, 34, 35,
+  36, 37, 38, 39, 40, 41, 42, 43,
+  44, 45, 46, 47, 48, 49, 50, 51,
+  52, 53, 54, 55, 56, 57, 58, 59,
+  60, 61, 62, 63 },
+   .oobfree = {
+   {.offset = 2,
+.length = 2} }
+};
+
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
return readl(nfc->regs + reg);
@@ -285,6 +334,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc, 
int column, int page)
ROW_ADDR_SHIFT, page);
 }
 
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+   vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+   CONFIG_ECC_MODE_MASK,
+   CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
 static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
 {
vf610_nfc_write(nfc, NFC_SECTOR_SIZE, size);
@@ -303,13 +359,20 @@ static void vf610_nfc_command(struct mtd_info *mtd, 
unsigned command,
case NAND_CMD_SEQIN:
/* Use valid column/page from preread... */
vf610_nfc_addr_cycle(nfc, column, page);
+   nfc->buf_offset = 0;
+
/*
 * SEQIN => data => PAGEPROG sequence is done by the controller
 * hence we do not ne

[PATCH v10 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

2015-08-03 Thread Stefan Agner
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 40 
 arch/arm/boot/dts/vfxxx.dtsi|  8 
 2 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..2a278a2 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,19 @@
};
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <24>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..2f4b04d 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,14 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
};
};
 };
-- 
2.5.0

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


[PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-08-03 Thread Stefan Agner
Signed-off-by: Bill Pringlemeir 
Acked-by: Shawn Guo 
Reviewed-by: Brian Norris 
Signed-off-by: Stefan Agner 
---
 .../devicetree/bindings/mtd/vf610-nfc.txt  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..cae5f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,45 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc"
+- reg: address range of the NFC
+- interrupts: interrupt of the NFC
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+
+Example:
+
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x400e 0x4000>;
+   interrupts = ;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
-- 
2.5.0

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


[PATCH v10 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610

2015-08-03 Thread Stefan Agner
The 10th revision includes some more review comments, including an
improved handling of empty NAND pages with hardware ECC.

More information and the full test log of earlier patchset version
can be found in the cover letter of the last revision v6:
http://thread.gmane.org/gmane.linux.kernel/1979868

Changes since v9:
- Remove inline of vf610_nfc_done
- Add __iomem to src argument of vf610_nfc_memcpy
- Handle return value of mtd_device_parse_register correctly
- Count bits in OOB too (only non-ECC bits)
- Return bitflips in ecc.read_page callback vf610_nfc_read_page
- Fall-through ALT_BUF_ONFI
- Use BIT macros

Changes since v8:
- Fix 16-Bit NAND flash support by splitting up initialization
  (introduce vf610_nfc_preinit_controller)
- Updated comments in initialziation functions

Changes since v7:
- vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node
  and sort new nfc node behind the existing iomuxc node as well.
- vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes

Changes since v6:
- Rebased ontop of l2-mtd/master (v4.2-rc1 based)
- Removed HAVE_NAND_VF610_NFC and use depends on. This made
  "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary

Changes since v5:
- Removed fsl,mpc5125-nfc compatible string
- Removed readl/writel_relaxed
- Change interface of vf610_nfc_transfer_size to match other accessors

Changes since v4:
- Rebased ontop of l2-mtd/master (v4.1-rc4 based)
- Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does
  not support sub-page writes anyway (improves write performance)
- Support ONFI by enabling READID command with offset and parameter page
  reads (CMD_PARAM)
- Change to dedicated read_page/write_page function, enables raw writes
- Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements
- Eliminated vf610_nfc_probe_dt in favor of common DT init code
- Use wait_for_completion_timeout
- Some style fixes (spaces, etc.)

Changes since v3:
- Make the driver selectable when COMPILE_TEST is set
- Fix compile error due to superfluous ECC_STATUS configuration in initial
  patch (without ECC correction ECC_STATUS does not need to be configured)
- Remove custom BBT pattern and switch to in-band BBT in the initial patch
- Include two bug fixes, for details see the corresponding U-Boot patches:
  http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802

Changes since v2:
- Updated binding documentation

Changes since v1:
- Nest nfc_config struct within the main nfc struct
- Use assigned clock binding to specify NFC clock
- Rebased ontop of MSCM IR patchset (driver parts have been merged)
- Split out arch Kconfig in a separate config
- Fix module license
- Updated MAINTAINERS

Changes since RFC (Bill Pringlemeir):
- Renamed driver from fsl_nfc to vf610_nfc
- Use readl/writel for all register in accessor functions
- Optimized field accessor functions
- Implemented PM (suspend/resume) functions
- Implemented basic support for ECC strength/ECC step size from dt
- Improved performance of count_written_bits by using hweight32
- Support ECC with 60-bytes to correct up to 32 bit errors
- Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes
  which uses up to 60 bytes on 64 byte OOB
- Removed custom (downstream) BBT pattern since BBT table won't be
  compatible anyway (due to the change above)

*** SUBJECT HERE ***

*** BLURB HERE ***

Stefan Agner (5):
  mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
  mtd: nand: vf610_nfc: add hardware BCH-ECC support
  mtd: nand: vf610_nfc: add device tree bindings
  ARM: dts: vf610twr: add NAND flash controller peripherial
  ARM: dts: vf-colibri: enable NAND flash controller

 .../devicetree/bindings/mtd/vf610-nfc.txt  |  45 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/vf-colibri.dtsi  |  32 +
 arch/arm/boot/dts/vf610-twr.dts|  40 +
 arch/arm/boot/dts/vfxxx.dtsi   |   8 +
 drivers/mtd/nand/Kconfig   |  11 +
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/vf610_nfc.c   | 849 +
 8 files changed, 992 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-07-31 Thread Stefan Agner
On 2015-08-01 01:47, Brian Norris wrote:
> On Sat, Aug 01, 2015 at 01:35:52AM +0200, Stefan Agner wrote:
>> On 2015-08-01 01:09, Brian Norris wrote:
> 
>> >> +static int vf610_nfc_read_page(struct mtd_info *mtd, struct nand_chip 
>> >> *chip,
>> >> + uint8_t *buf, int oob_required, int page)
>> >> +{
>> >> + int eccsize = chip->ecc.size;
>> >> + int stat;
>> >> +
>> >> + vf610_nfc_read_buf(mtd, buf, eccsize);
>> >> +
>> >> + if (oob_required)
>> >> + vf610_nfc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
>> >
>> > To fix the bitflips issue above, you'll just want to unconditionally
>> > read the OOB (it's fine to ignore 'oob_required') and...
>> >
>> >> +
>> >> + stat = vf610_nfc_correct_data(mtd, buf);
>> >
>> > ...pass in chip->oob_poi as a third argument.
>> >
>>
>> Hm, this probably will have an effect on performance, since we usually
>> omit the OOB if not requested.
> 
> You could test :) I don't really like performance claims without tests.
> (I say this because I added the oob_required flag myself, but just for
> functional purposes, not performance. Many drivers got by just fine by
> always copying the OOB data.)

Did the measurement:

As is:
...
[   30.955675] mtd_speedtest: testing eraseblock write speed
[  143.349572] mtd_speedtest: eraseblock write speed is 4641 KiB/s
[  143.355606] mtd_speedtest: testing eraseblock read speed
[  183.816690] mtd_speedtest: eraseblock read speed is 12893 KiB/s
[  185.874702] mtd_speedtest: testing page write speed
[  302.608719] mtd_speedtest: page write speed is 4468 KiB/s
[  302.614229] mtd_speedtest: testing page read speed
[  343.831663] mtd_speedtest: page read speed is 12656 KiB/s
...

Unconditionally read OOB:
...
[   29.076983] mtd_speedtest: testing eraseblock write speed
[  140.829920] mtd_speedtest: eraseblock write speed is 4667 KiB/s
[  140.835960] mtd_speedtest: testing eraseblock read speed
[  181.594498] mtd_speedtest: eraseblock read speed is 12798 KiB/s
[  183.652793] mtd_speedtest: testing page write speed
[  299.772069] mtd_speedtest: page write speed is 4492 KiB/s
[  299.777583] mtd_speedtest: testing page read speed
[  341.283668] mtd_speedtest: page read speed is 12568 KiB/s
...

And with conditional OOB again, reading OOB if required in
vf610_nfc_correct_data.
...
[   29.907147] mtd_speedtest: testing eraseblock write speed
[  141.146171] mtd_speedtest: eraseblock write speed is 4689 KiB/s
[  141.152185] mtd_speedtest: testing eraseblock read speed
[  181.644380] mtd_speedtest: eraseblock read speed is 12883 KiB/s
[  183.703198] mtd_speedtest: testing page write speed
[  299.423179] mtd_speedtest: page write speed is 4507 KiB/s
[  299.428671] mtd_speedtest: testing page read speed
[  340.695925] mtd_speedtest: page read speed is 12640 KiB/s
[  342.747510] mtd_speedtest: testing 2 page write speed
...

The last test is probably pointless since we never read a empty page in
the speedtest. So performance hit is measurable but small (somewhat
below 100KiB/s).

This is with 64 bytes OOB. Since OOB sizes are only getting bigger, I
would rather still consider it... What do you think?

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-07-31 Thread Stefan Agner
Hi Brian,

On 2015-08-01 01:09, Brian Norris wrote:

>> +static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t *dat)
>> +{
>> +struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>> +u8 ecc_status;
>> +u8 ecc_count;
>> +int flip;
>> +
>> +ecc_status = __raw_readb(nfc->regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
>> +ecc_count = ecc_status & ECC_ERR_COUNT;
>> +if (!(ecc_status & ECC_STATUS_MASK))
>> +return ecc_count;
>> +
>> +/*
>> + * On an erased page, bit count should be zero or at least
>> + * less then half of the ECC strength
>> + */
>> +flip = count_written_bits(dat, nfc->chip.ecc.size, ecc_count);
> 
> Sorry I didn't notice this earlier, but it appears you are falling into
> the same trap that almost everyone else is -- it is not sufficient to
> check just the page area; you also need to check the OOB. Suppose that
> a MTD user wrote mostly-0xff data to the page, then the page accumulates
> bitflips in the spare area and a few in the page area, such that
> eventually HW ECC can't correct them. If there are few enough zero bits
> in the data area, you will mistakenly think that this is a blank page
> below, and memset() it to 0xff. That would be disastrous!
> 
> Fortunately, your code is otherwise quite well structured and looks
> good. A tip below.
> 
>> +
>> +if (flip > ecc_count && flip > (nfc->chip.ecc.strength / 2))
>> +return -1;
>> +
>> +/* Erased page. */
>> +memset(dat, 0xff, nfc->chip.ecc.size);
>> +return 0;
>> +}
>> +
>> +static int vf610_nfc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
>> +uint8_t *buf, int oob_required, int page)
>> +{
>> +int eccsize = chip->ecc.size;
>> +int stat;
>> +
>> +vf610_nfc_read_buf(mtd, buf, eccsize);
>> +
>> +if (oob_required)
>> +vf610_nfc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
> 
> To fix the bitflips issue above, you'll just want to unconditionally
> read the OOB (it's fine to ignore 'oob_required') and...
> 
>> +
>> +stat = vf610_nfc_correct_data(mtd, buf);
> 
> ...pass in chip->oob_poi as a third argument.
> 

Hm, this probably will have an effect on performance, since we usually
omit the OOB if not requested. I could fetch the OOB from the NAND
controllers SRAM only if necessary (if HW ECC status is not ok...). Does
this sound reasonable?

>> +
>> +if (stat < 0)
>> +mtd->ecc_stats.failed++;
>> +else
>> +mtd->ecc_stats.corrected += stat;
> 
> You've got another problem here: ecc.read_page() should be returning
> 'max_bitflips' here. So, since you have a single ECC region, this block
> should probably be:
> 
>   if (stat < 0) {
>   mtd->ecc_stats.failed++;
>   return 0;
>   } else {
>   mtd->ecc_stats.corrected += stat;
>   return stat;
>   }
> 

Ok, will change that.

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-07-31 Thread Stefan Agner
On 2015-07-31 18:52, Stefan Agner wrote:
> Signed-off-by: Bill Pringlemeir 
> Signed-off-by: Stefan Agner 

Actually just realized that I forgot to collect the Ack of Shawn, will
add that in next revision as well.

FWIW, dispatching to some recipients have been deferred (e.g. the
mailing lists) due to DNS issues on my side, sorry about that.

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] ARM: dts: vf-colibri: define stdout-path property

2015-07-31 Thread Stefan Agner
Hi Shawn,

Did you notice this change? Just asking since you applied some other
changes already...

--
Stefan

On 2015-07-15 16:50, Stefan Agner wrote:
> Define Vybrid's UART0, connected to the Colibri pinout UART_A, as
> standard output.
> 
> Signed-off-by: Stefan Agner 
> ---
>  arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> index 77e1a45..2ce6fe5 100644
> --- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> +++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> @@ -9,7 +9,7 @@
>  
>  / {
>   chosen {
> - bootargs = "console=ttyLP0,115200";
> + stdout-path = "serial0:115200n8";
>   };
>  
>   clk16m: clk16m {

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


[PATCH v9 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610

2015-07-31 Thread Stefan Agner
The ninth revision fixes 16-Bit NAND flash support.

More information and the full test log of earlier patchset version
can be found in the cover letter of the last revision v6:
http://thread.gmane.org/gmane.linux.kernel/1979868

Changes since v8:
- Fix 16-Bit NAND flash support by splitting up initialization
  (introduce vf610_nfc_preinit_controller)
- Updated comments in initialziation functions

Changes since v7:
- vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node
  and sort new nfc node behind the existing iomuxc node as well.
- vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes

Changes since v6:
- Rebased ontop of l2-mtd/master (v4.2-rc1 based)
- Removed HAVE_NAND_VF610_NFC and use depends on. This made
  "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary

Changes since v5:
- Removed fsl,mpc5125-nfc compatible string
- Removed readl/writel_relaxed
- Change interface of vf610_nfc_transfer_size to match other accessors

Changes since v4:
- Rebased ontop of l2-mtd/master (v4.1-rc4 based)
- Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does
  not support sub-page writes anyway (improves write performance)
- Support ONFI by enabling READID command with offset and parameter page
  reads (CMD_PARAM)
- Change to dedicated read_page/write_page function, enables raw writes
- Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements
- Eliminated vf610_nfc_probe_dt in favor of common DT init code
- Use wait_for_completion_timeout
- Some style fixes (spaces, etc.)

Changes since v3:
- Make the driver selectable when COMPILE_TEST is set
- Fix compile error due to superfluous ECC_STATUS configuration in initial
  patch (without ECC correction ECC_STATUS does not need to be configured)
- Remove custom BBT pattern and switch to in-band BBT in the initial patch
- Include two bug fixes, for details see the corresponding U-Boot patches:
  http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802

Changes since v2:
- Updated binding documentation

Changes since v1:
- Nest nfc_config struct within the main nfc struct
- Use assigned clock binding to specify NFC clock
- Rebased ontop of MSCM IR patchset (driver parts have been merged)
- Split out arch Kconfig in a separate config
- Fix module license
- Updated MAINTAINERS

Changes since RFC (Bill Pringlemeir):
- Renamed driver from fsl_nfc to vf610_nfc
- Use readl/writel for all register in accessor functions
- Optimized field accessor functions
- Implemented PM (suspend/resume) functions
- Implemented basic support for ECC strength/ECC step size from dt
- Improved performance of count_written_bits by using hweight32
- Support ECC with 60-bytes to correct up to 32 bit errors
- Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes
  which uses up to 60 bytes on 64 byte OOB
- Removed custom (downstream) BBT pattern since BBT table won't be
  compatible anyway (due to the change above)

Stefan Agner (5):
  mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
  mtd: nand: vf610_nfc: add hardware BCH-ECC support
  mtd: nand: vf610_nfc: add device tree bindings
  ARM: dts: vf610twr: add NAND flash controller peripherial
  ARM: dts: vf-colibri: enable NAND flash controller

 .../devicetree/bindings/mtd/vf610-nfc.txt  |  45 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/vf-colibri.dtsi  |  32 +
 arch/arm/boot/dts/vf610-twr.dts|  40 +
 arch/arm/boot/dts/vfxxx.dtsi   |   8 +
 drivers/mtd/nand/Kconfig   |  11 +
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/vf610_nfc.c   | 843 +
 8 files changed, 986 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

-- 
2.4.5

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


Re: [PATCH v7 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-07-31 Thread Stefan Agner
Hi Alexey,

[converted back to plain text]
On 2015-08-01 00:54, Alexey Klimov wrote: 
> just two small questions. 
> 
> On Jul 24, 2015 4:20 PM, "Stefan Agner"  wrote:
>> 
>> This driver supports Freescale NFC (NAND flash controller) found on
>> Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
>> been tested on 8-bit and 16-bit NAND interface and supports ONFI
>> parameter page reading.
>> 
>> Limitations:
>> - DMA and pipelining not used
>> - Pages larger than 2k are not supported
>> - No hardware ECC
>> 
>> The driver has only been tested on Vybrid SoC VF610 and VF500.
>> 
>> Some paths have been hand-optimized and evaluated by measurements
>> made using mtd_speedtest.ko on a 100MB MTD partition.
>> 
>> Colibri VF50
>> eb write % eb read % page write % page read %
>> rel/opt 5175 11537 4560 11039
>> opt 5164 -0.21 11420 -1.01 4737 +3.88 10918 -1.10
>> none 5113 -1.20 11352 -1.60 4490 -1.54 10865 -1.58
>> 
>> Colibri VF61
>> eb write % eb read % page write % page read %
>> rel/opt 5766 13096 5459 12846
>> opt 5883 +2.03 13064 -0.24 5561 +1.87 12802 -0.34
>> none 5701 -1.13 12980 -0.89 5488 +0.53 12735 -0.86
>> 
>> rel = using readl_relaxed/writel_relaxed in optimized paths
>> opt = hand-optimized by combining multiple accesses into one read/write
>> 
>> The measurements have not been statistically verfied, hence use them
>> with care. The author came to the conclusion that using the relaxed
>> variants of readl/writel are not worth the additional code.
>> 
>> Signed-off-by: Bill Pringlemeir 
>> Signed-off-by: Stefan Agner 
>> ---
>> MAINTAINERS | 6 +
>> drivers/mtd/nand/Kconfig | 9 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/vf610_nfc.c | 640 
>> +++
>> 4 files changed, 656 insertions(+)
>> create mode 100644 drivers/mtd/nand/vf610_nfc.c
>> 
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 9567329..59975c7 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -10835,6 +10835,12 @@ S: Maintained
>> F: Documentation/fb/uvesafb.txt
>> F: drivers/video/fbdev/uvesafb.*
>> 
>> +VF610 NAND DRIVER
>> +M: Stefan Agner 
>> +L: linux-...@lists.infradead.org
>> +S: Supported
>> +F: drivers/mtd/nand/vf610_nfc.c
>> +
>> VFAT/FAT/MSDOS FILESYSTEM
>> M: OGAWA Hirofumi 
>> S: Maintained
>> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>> index 5b2806a..8550b14 100644
>> --- a/drivers/mtd/nand/Kconfig
>> +++ b/drivers/mtd/nand/Kconfig
>> @@ -463,6 +463,15 @@ config MTD_NAND_MPC5121_NFC
>> This enables the driver for the NAND flash controller on the
>> MPC5121 SoC.
>> 
>> +config MTD_NAND_VF610_NFC
>> + tristate "Support for Freescale NFC for VF610/MPC5125"
>> + depends on (SOC_VF610 || COMPILE_TEST)
>> + help
>> + Enables support for NAND Flash Controller on some Freescale
>> + processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
>> + The driver supports a maximum 2k page size. The driver
>> + currently does not support hardware ECC.
>> +
>> config MTD_NAND_MXC
>> tristate "MXC NAND support"
>> depends on ARCH_MXC
>> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
>> index 1f897ec..a490af8 100644
>> --- a/drivers/mtd/nand/Makefile
>> +++ b/drivers/mtd/nand/Makefile
>> @@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES) += socrates_nand.o
>> obj-$(CONFIG_MTD_NAND_TXX9NDFMC) += txx9ndfmc.o
>> obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o
>> obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
>> +obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o
>> obj-$(CONFIG_MTD_NAND_RICOH) += r852.o
>> obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
>> obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/
>> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
>> new file mode 100644
>> index 000..0da500e
>> --- /dev/null
>> +++ b/drivers/mtd/nand/vf610_nfc.c
>> @@ -0,0 +1,640 @@
>> +/*
>> + * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
>> + *
>> + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
>> + * Jason ported to M54418TWR and MVFA5 (VF610).
>> + * Authors: Stefan Agner 
>> + * Bill Pringlemeir 
>> + * Shaohui Xie 
>> + * Jason Jin 
>> + *
>> + * Based on original driver mpc5121_nfc.c.
>> + *
>> + * This is free software; you can redistribut

[PATCH v9 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-07-31 Thread Stefan Agner
This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
been tested on 8-bit and 16-bit NAND interface and supports ONFI
parameter page reading.

Limitations:
- DMA and pipelining not used
- Pages larger than 2k are not supported
- No hardware ECC

The driver has only been tested on Vybrid SoC VF610 and VF500.

Some paths have been hand-optimized and evaluated by measurements
made using mtd_speedtest.ko on a 100MB MTD partition.

Colibri VF50
eb write %   eb read %   page write  %   page read %
rel/opt 5175   115374560 11039
opt 5164 -0.21 11420 -1.01  4737 +3.88   10918 -1.10
none5113 -1.20 11352 -1.60  4490 -1.54   10865 -1.58

Colibri VF61
eb write %   eb read %   page write  %   page read %
rel/opt 5766   130965459 12846
opt 5883 +2.03 13064 -0.24  5561 +1.87   12802 -0.34
none5701 -1.13 12980 -0.89  5488 +0.53   12735 -0.86

rel = using readl_relaxed/writel_relaxed in optimized paths
opt = hand-optimized by combining multiple accesses into one read/write

The measurements have not been statistically verfied, hence use them
with care. The author came to the conclusion that using the relaxed
variants of readl/writel are not worth the additional code.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 MAINTAINERS  |   6 +
 drivers/mtd/nand/Kconfig |   9 +
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 644 +++
 4 files changed, 660 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9567329..59975c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10835,6 +10835,12 @@ S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
 
+VF610 NAND DRIVER
+M: Stefan Agner 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/vf610_nfc.c
+
 VFAT/FAT/MSDOS FILESYSTEM
 M: OGAWA Hirofumi 
 S: Maintained
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5b2806a..8550b14 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -463,6 +463,15 @@ config MTD_NAND_MPC5121_NFC
  This enables the driver for the NAND flash controller on the
  MPC5121 SoC.
 
+config MTD_NAND_VF610_NFC
+   tristate "Support for Freescale NFC for VF610/MPC5125"
+   depends on (SOC_VF610 || COMPILE_TEST)
+   help
+ Enables support for NAND Flash Controller on some Freescale
+ processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
+ The driver supports a maximum 2k page size. The driver
+ currently does not support hardware ECC.
+
 config MTD_NAND_MXC
tristate "MXC NAND support"
depends on ARCH_MXC
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..a490af8 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES)   += 
socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)   += txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)  += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..d9fc73f
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,644 @@
+/*
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Jason ported to M54418TWR and MVFA5 (VF610).
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This 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.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA not used.
+ * - 2K pages or less.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"vf610_nfc"
+
+/* Register Offsets */
+#define NFC_FLASH_CMD1 0x3F00
+#define NFC_FLASH_CMD2 0x3F04
+#define NFC_COL_ADDR   0x3F08
+#define NFC_ROW_ADDR   0x

[PATCH v9 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-07-31 Thread Stefan Agner
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages). Raw writes writes
are possible through the common nand_write_page_raw implementation,
however raw reads are not possible since the hardware ECC mode need
to be enabled at command time.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Kconfig |   6 +-
 drivers/mtd/nand/vf610_nfc.c | 201 ++-
 2 files changed, 204 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8550b14..e05f53c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -469,8 +469,10 @@ config MTD_NAND_VF610_NFC
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
 
 config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index d9fc73f..b87841c 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,6 +19,8 @@
  * - Untested on MPC5125 and M54418.
  * - DMA not used.
  * - 2K pages or less.
+ * - Only 2K page w. 64+ OOB and hardware ECC.
+ * - Raw page reads not implemented when using ECC.
  */
 
 #include 
@@ -72,6 +74,8 @@
 
 /* NFC ECC mode define */
 #define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
 
 /*** Register Mask and bit definitions */
 
@@ -104,6 +108,8 @@
 #define STATUS_BYTE1_MASK  0x00FF
 
 /* NFC_FLASH_CONFIG Field */
+#define CONFIG_ECC_SRAM_ADDR_MASK  0x7FC0
+#define CONFIG_ECC_SRAM_ADDR_SHIFT 22
 #define CONFIG_ECC_SRAM_REQ_BIT(1<<21)
 #define CONFIG_DMA_REQ_BIT (1<<20)
 #define CONFIG_ECC_MODE_MASK   0x000E
@@ -122,6 +128,21 @@
 #define CMD_DONE_CLEAR_BIT (1<<18)
 #define IDLE_CLEAR_BIT (1<<17)
 
+/* ECC status placed at end of buffers. */
+#define ECC_SRAM_ADDR  ((PAGE_2K + 256 - 8) >> 3)
+#define ECC_STATUS_MASK0x80
+#define ECC_ERR_COUNT  0x3F
+
+/*
+ * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
+ * and +7 for big-endian SoCs.
+ */
+#ifdef __LITTLE_ENDIAN
+#define ECC_OFFSET 4
+#else
+#define ECC_OFFSET 7
+#endif
+
 struct vf610_nfc {
struct mtd_info mtd;
struct nand_chip chip;
@@ -136,10 +157,40 @@ struct vf610_nfc {
 #define ALT_BUF_STAT 2
 #define ALT_BUF_ONFI 3
struct clk *clk;
+   bool use_hw_ecc;
+   u32 ecc_mode;
 };
 
 #define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
 
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+   .eccbytes = 45,
+   .eccpos = {19, 20, 21, 22, 23,
+  24, 25, 26, 27, 28, 29, 30, 31,
+  32, 33, 34, 35, 36, 37, 38, 39,
+  40, 41, 42, 43, 44, 45, 46, 47,
+  48, 49, 50, 51, 52, 53, 54, 55,
+  56, 57, 58, 59, 60, 61, 62, 63},
+   .oobfree = {
+   {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+   .eccbytes = 60,
+   .eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
+  12, 13, 14, 15, 16, 17, 18, 19,
+  20, 21, 22, 23, 24, 25, 26, 27,
+  28, 29, 30, 31, 32, 33, 34, 35,
+  36, 37, 38, 39, 40, 41, 42, 43,
+  44, 45, 46, 47, 48, 49, 50, 51,
+  52, 53, 54, 55, 56, 57, 58, 59,
+  60, 61, 62, 63 },
+   .oobfree = {
+   {.offset = 2,
+.length = 2} }
+};
+
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
return readl(nfc->regs + reg);
@@ -281,6 +332,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc, 
int column, int page)
ROW_ADDR_SHIFT, page);
 }
 
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+   vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+   CONFIG_ECC_MODE_MASK,
+   CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
 static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
 {
vf610_nfc_write(nfc, NFC_SECTOR_SIZE, size);
@@ -299,

[PATCH v9 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-07-31 Thread Stefan Agner
Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 .../devicetree/bindings/mtd/vf610-nfc.txt  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..cae5f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,45 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc"
+- reg: address range of the NFC
+- interrupts: interrupt of the NFC
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+
+Example:
+
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x400e 0x4000>;
+   interrupts = ;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
-- 
2.4.5

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


[PATCH v9 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

2015-07-31 Thread Stefan Agner
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 40 
 arch/arm/boot/dts/vfxxx.dtsi|  8 
 2 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..2a278a2 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,19 @@
};
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <24>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..2f4b04d 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,14 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
};
};
 };
-- 
2.4.5

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


Re: [PATCH v8 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-07-31 Thread Stefan Agner
Hi Albert,

On 2015-07-30 18:13, Albert ARIBAUD wrote:
> Hi Stefan,
> 
> Le Mon, 27 Jul 2015 18:42:41 +0200, Stefan Agner  a
> écrit :
> 
>> This driver supports Freescale NFC (NAND flash controller) found on
>> Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
>> been tested on 8-bit and 16-bit NAND interface and supports ONFI
>> parameter page reading.
>>
>> [...]
>>
>> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
>> new file mode 100644
>> index 000..0da500e
>> --- /dev/null
>> +++ b/drivers/mtd/nand/vf610_nfc.c
>> @@ -0,0 +1,640 @@
>> [...]
> 
> ... about line 708:
> 
>> +err = devm_request_irq(nfc->dev, irq, vf610_nfc_irq, 0, DRV_NAME, mtd);
>> +if (err) {
>> +dev_err(nfc->dev, "Error requesting IRQ!\n");
>> +goto error;
>> +}
>> +
>> +vf610_nfc_init_controller(nfc);
> 
> The call above is too early: vf610_nfc_init_controller() will test
> for (nfc->chip.options & NAND_BUSWIDTH_16) but this option bit is only
> set once nand_scan_ident() below has been run.
> 
> This has the effect that even when the DT node specifies a 16-bit wide
> bus, the controller is configured for 8-bit mode at this point, which of
> course causes read failures. I've experienced this with a Vybrid SoC
> and a Micron MT29F4G16ABADAH4 16-bit NAND.
> 
>> +/* first scan to find the device and get the page size */
>> +if (nand_scan_ident(mtd, 1, NULL)) {
>> +err = -ENXIO;
>> +goto error;
>> +}
> 
> Placing the call to vf610_nfc_init_controller() here, after the call
> to nand_scan_ident() rather than before it, fixed the issue for me.

Hm, since nand_scan_ident access the devices we actually want the
controller initialized before we access it the first time. In most
cases, the boot loader/boot ROM probably initialized the controller in a
way that identifying the chip should work non the less. However, the
safe way would be to initialize it before calling nand_scan_ident.

However, I see your point regarding bus width: With the change to
nand_dt_init, we have that information after nand_scan_ident. There is
actually more: Also the HW ECC settings are not yet parsed at that
point, hence the ECC status and offset will not be initialized right. 

We could call the whole initialization twice. This would configure 8-Bit
mode for the 16-Bit devices, but during initialization this is anyway
the required default (ONFI). Or we split it up and call it something
like vf610_nfc_preinit_controller and vf610_nfc_init_controller.

What do you think?

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


[PATCH v9 5/5] ARM: dts: vf-colibri: enable NAND flash controller

2015-07-31 Thread Stefan Agner
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..ab2e74b 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,19 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <32>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +169,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.4.5

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


[PATCH v8 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610

2015-07-27 Thread Stefan Agner
The eigth revision fixes some rough spots in the device trees.

More information and the full test log of earlier patchset version
can be found in the cover letter of the last revision v6:
http://thread.gmane.org/gmane.linux.kernel/1979868

Changes since v7:
- vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node
  and sort new nfc node behind the existing iomuxc node as well.
- vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes

Changes since v6:
- Rebased ontop of l2-mtd/master (v4.2-rc1 based)
- Removed HAVE_NAND_VF610_NFC and use depends on. This made
  "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary

Changes since v5:
- Removed fsl,mpc5125-nfc compatible string
- Removed readl/writel_relaxed
- Change interface of vf610_nfc_transfer_size to match other accessors

Changes since v4:
- Rebased ontop of l2-mtd/master (v4.1-rc4 based)
- Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does
  not support sub-page writes anyway (improves write performance)
- Support ONFI by enabling READID command with offset and parameter page
  reads (CMD_PARAM)
- Change to dedicated read_page/write_page function, enables raw writes
- Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements
- Eliminated vf610_nfc_probe_dt in favor of common DT init code
- Use wait_for_completion_timeout
- Some style fixes (spaces, etc.)

Changes since v3:
- Make the driver selectable when COMPILE_TEST is set
- Fix compile error due to superfluous ECC_STATUS configuration in initial
  patch (without ECC correction ECC_STATUS does not need to be configured)
- Remove custom BBT pattern and switch to in-band BBT in the initial patch
- Include two bug fixes, for details see the corresponding U-Boot patches:
  http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802

Changes since v2:
- Updated binding documentation

Changes since v1:
- Nest nfc_config struct within the main nfc struct
- Use assigned clock binding to specify NFC clock
- Rebased ontop of MSCM IR patchset (driver parts have been merged)
- Split out arch Kconfig in a separate config
- Fix module license
- Updated MAINTAINERS

Changes since RFC (Bill Pringlemeir):
- Renamed driver from fsl_nfc to vf610_nfc
- Use readl/writel for all register in accessor functions
- Optimized field accessor functions
- Implemented PM (suspend/resume) functions
- Implemented basic support for ECC strength/ECC step size from dt
- Improved performance of count_written_bits by using hweight32
- Support ECC with 60-bytes to correct up to 32 bit errors
- Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes
  which uses up to 60 bytes on 64 byte OOB
- Removed custom (downstream) BBT pattern since BBT table won't be
  compatible anyway (due to the change above)

Stefan Agner (5):
  mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
  mtd: nand: vf610_nfc: add hardware BCH-ECC support
  mtd: nand: vf610_nfc: add device tree bindings
  ARM: dts: vf610twr: add NAND flash controller peripherial
  ARM: dts: vf-colibri: enable NAND flash controller

 .../devicetree/bindings/mtd/vf610-nfc.txt  |  45 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/vf-colibri.dtsi  |  32 +
 arch/arm/boot/dts/vf610-twr.dts|  40 +
 arch/arm/boot/dts/vfxxx.dtsi   |   8 +
 drivers/mtd/nand/Kconfig   |  11 +
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/vf610_nfc.c   | 839 +
 8 files changed, 982 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

-- 
2.4.5

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


[PATCH v8 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-07-27 Thread Stefan Agner
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages). Raw writes writes
are possible through the common nand_write_page_raw implementation,
however raw reads are not possible since the hardware ECC mode need
to be enabled at command time.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Kconfig |   6 +-
 drivers/mtd/nand/vf610_nfc.c | 201 ++-
 2 files changed, 204 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8550b14..e05f53c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -469,8 +469,10 @@ config MTD_NAND_VF610_NFC
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
 
 config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 0da500e..4d795a5 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,6 +19,8 @@
  * - Untested on MPC5125 and M54418.
  * - DMA not used.
  * - 2K pages or less.
+ * - Only 2K page w. 64+ OOB and hardware ECC.
+ * - Raw page reads not implemented when using ECC.
  */
 
 #include 
@@ -72,6 +74,8 @@
 
 /* NFC ECC mode define */
 #define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
 
 /*** Register Mask and bit definitions */
 
@@ -104,6 +108,8 @@
 #define STATUS_BYTE1_MASK  0x00FF
 
 /* NFC_FLASH_CONFIG Field */
+#define CONFIG_ECC_SRAM_ADDR_MASK  0x7FC0
+#define CONFIG_ECC_SRAM_ADDR_SHIFT 22
 #define CONFIG_ECC_SRAM_REQ_BIT(1<<21)
 #define CONFIG_DMA_REQ_BIT (1<<20)
 #define CONFIG_ECC_MODE_MASK   0x000E
@@ -122,6 +128,21 @@
 #define CMD_DONE_CLEAR_BIT (1<<18)
 #define IDLE_CLEAR_BIT (1<<17)
 
+/* ECC status placed at end of buffers. */
+#define ECC_SRAM_ADDR  ((PAGE_2K + 256 - 8) >> 3)
+#define ECC_STATUS_MASK0x80
+#define ECC_ERR_COUNT  0x3F
+
+/*
+ * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
+ * and +7 for big-endian SoCs.
+ */
+#ifdef __LITTLE_ENDIAN
+#define ECC_OFFSET 4
+#else
+#define ECC_OFFSET 7
+#endif
+
 struct vf610_nfc {
struct mtd_info mtd;
struct nand_chip chip;
@@ -136,10 +157,40 @@ struct vf610_nfc {
 #define ALT_BUF_STAT 2
 #define ALT_BUF_ONFI 3
struct clk *clk;
+   bool use_hw_ecc;
+   u32 ecc_mode;
 };
 
 #define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
 
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+   .eccbytes = 45,
+   .eccpos = {19, 20, 21, 22, 23,
+  24, 25, 26, 27, 28, 29, 30, 31,
+  32, 33, 34, 35, 36, 37, 38, 39,
+  40, 41, 42, 43, 44, 45, 46, 47,
+  48, 49, 50, 51, 52, 53, 54, 55,
+  56, 57, 58, 59, 60, 61, 62, 63},
+   .oobfree = {
+   {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+   .eccbytes = 60,
+   .eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
+  12, 13, 14, 15, 16, 17, 18, 19,
+  20, 21, 22, 23, 24, 25, 26, 27,
+  28, 29, 30, 31, 32, 33, 34, 35,
+  36, 37, 38, 39, 40, 41, 42, 43,
+  44, 45, 46, 47, 48, 49, 50, 51,
+  52, 53, 54, 55, 56, 57, 58, 59,
+  60, 61, 62, 63 },
+   .oobfree = {
+   {.offset = 2,
+.length = 2} }
+};
+
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
return readl(nfc->regs + reg);
@@ -281,6 +332,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc, 
int column, int page)
ROW_ADDR_SHIFT, page);
 }
 
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+   vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+   CONFIG_ECC_MODE_MASK,
+   CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
 static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
 {
vf610_nfc_write(nfc, NFC_SECTOR_SIZE, size);
@@ -299,

[PATCH v8 5/5] ARM: dts: vf-colibri: enable NAND flash controller

2015-07-27 Thread Stefan Agner
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..ab2e74b 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,19 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <32>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +169,25 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.4.5

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


[PATCH v8 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-07-27 Thread Stefan Agner
This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
been tested on 8-bit and 16-bit NAND interface and supports ONFI
parameter page reading.

Limitations:
- DMA and pipelining not used
- Pages larger than 2k are not supported
- No hardware ECC

The driver has only been tested on Vybrid SoC VF610 and VF500.

Some paths have been hand-optimized and evaluated by measurements
made using mtd_speedtest.ko on a 100MB MTD partition.

Colibri VF50
eb write %   eb read %   page write  %   page read %
rel/opt 5175   115374560 11039
opt 5164 -0.21 11420 -1.01  4737 +3.88   10918 -1.10
none5113 -1.20 11352 -1.60  4490 -1.54   10865 -1.58

Colibri VF61
eb write %   eb read %   page write  %   page read %
rel/opt 5766   130965459 12846
opt 5883 +2.03 13064 -0.24  5561 +1.87   12802 -0.34
none5701 -1.13 12980 -0.89  5488 +0.53   12735 -0.86

rel = using readl_relaxed/writel_relaxed in optimized paths
opt = hand-optimized by combining multiple accesses into one read/write

The measurements have not been statistically verfied, hence use them
with care. The author came to the conclusion that using the relaxed
variants of readl/writel are not worth the additional code.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 MAINTAINERS  |   6 +
 drivers/mtd/nand/Kconfig |   9 +
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 640 +++
 4 files changed, 656 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9567329..59975c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10835,6 +10835,12 @@ S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
 
+VF610 NAND DRIVER
+M: Stefan Agner 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/vf610_nfc.c
+
 VFAT/FAT/MSDOS FILESYSTEM
 M: OGAWA Hirofumi 
 S: Maintained
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5b2806a..8550b14 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -463,6 +463,15 @@ config MTD_NAND_MPC5121_NFC
  This enables the driver for the NAND flash controller on the
  MPC5121 SoC.
 
+config MTD_NAND_VF610_NFC
+   tristate "Support for Freescale NFC for VF610/MPC5125"
+   depends on (SOC_VF610 || COMPILE_TEST)
+   help
+ Enables support for NAND Flash Controller on some Freescale
+ processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
+ The driver supports a maximum 2k page size. The driver
+ currently does not support hardware ECC.
+
 config MTD_NAND_MXC
tristate "MXC NAND support"
depends on ARCH_MXC
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..a490af8 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES)   += 
socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)   += txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)  += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..0da500e
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,640 @@
+/*
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Jason ported to M54418TWR and MVFA5 (VF610).
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This 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.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA not used.
+ * - 2K pages or less.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"vf610_nfc"
+
+/* Register Offsets */
+#define NFC_FLASH_CMD1 0x3F00
+#define NFC_FLASH_CMD2 0x3F04
+#define NFC_COL_ADDR   0x3F08
+#define NFC_ROW_ADDR   0x

[PATCH v8 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

2015-07-27 Thread Stefan Agner
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 40 
 arch/arm/boot/dts/vfxxx.dtsi|  8 
 2 files changed, 48 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..2a278a2 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
>;
};
 
+   pinctrl_nfc: nfcgrp {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,19 @@
};
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <24>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc>;
+   status = "okay";
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..2f4b04d 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,14 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
};
};
 };
-- 
2.4.5

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


[PATCH v8 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-07-27 Thread Stefan Agner
Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 .../devicetree/bindings/mtd/vf610-nfc.txt  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..cae5f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,45 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc"
+- reg: address range of the NFC
+- interrupts: interrupt of the NFC
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+
+Example:
+
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x400e 0x4000>;
+   interrupts = ;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
-- 
2.4.5

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


[PATCH v7 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others

2015-07-24 Thread Stefan Agner
This driver supports Freescale NFC (NAND flash controller) found on
Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
been tested on 8-bit and 16-bit NAND interface and supports ONFI
parameter page reading.

Limitations:
- DMA and pipelining not used
- Pages larger than 2k are not supported
- No hardware ECC

The driver has only been tested on Vybrid SoC VF610 and VF500.

Some paths have been hand-optimized and evaluated by measurements
made using mtd_speedtest.ko on a 100MB MTD partition.

Colibri VF50
eb write %   eb read %   page write  %   page read %
rel/opt 5175   115374560 11039
opt 5164 -0.21 11420 -1.01  4737 +3.88   10918 -1.10
none5113 -1.20 11352 -1.60  4490 -1.54   10865 -1.58

Colibri VF61
eb write %   eb read %   page write  %   page read %
rel/opt 5766   130965459 12846
opt 5883 +2.03 13064 -0.24  5561 +1.87   12802 -0.34
none5701 -1.13 12980 -0.89  5488 +0.53   12735 -0.86

rel = using readl_relaxed/writel_relaxed in optimized paths
opt = hand-optimized by combining multiple accesses into one read/write

The measurements have not been statistically verfied, hence use them
with care. The author came to the conclusion that using the relaxed
variants of readl/writel are not worth the additional code.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 MAINTAINERS  |   6 +
 drivers/mtd/nand/Kconfig |   9 +
 drivers/mtd/nand/Makefile|   1 +
 drivers/mtd/nand/vf610_nfc.c | 640 +++
 4 files changed, 656 insertions(+)
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9567329..59975c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10835,6 +10835,12 @@ S: Maintained
 F: Documentation/fb/uvesafb.txt
 F: drivers/video/fbdev/uvesafb.*
 
+VF610 NAND DRIVER
+M: Stefan Agner 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/vf610_nfc.c
+
 VFAT/FAT/MSDOS FILESYSTEM
 M: OGAWA Hirofumi 
 S: Maintained
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5b2806a..8550b14 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -463,6 +463,15 @@ config MTD_NAND_MPC5121_NFC
  This enables the driver for the NAND flash controller on the
  MPC5121 SoC.
 
+config MTD_NAND_VF610_NFC
+   tristate "Support for Freescale NFC for VF610/MPC5125"
+   depends on (SOC_VF610 || COMPILE_TEST)
+   help
+ Enables support for NAND Flash Controller on some Freescale
+ processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
+ The driver supports a maximum 2k page size. The driver
+ currently does not support hardware ECC.
+
 config MTD_NAND_MXC
tristate "MXC NAND support"
depends on ARCH_MXC
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..a490af8 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES)   += 
socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)   += txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)  += nuc900_nand.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o
+obj-$(CONFIG_MTD_NAND_VF610_NFC)   += vf610_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)   += r852.o
 obj-$(CONFIG_MTD_NAND_JZ4740)  += jz4740_nand.o
 obj-$(CONFIG_MTD_NAND_GPMI_NAND)   += gpmi-nand/
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
new file mode 100644
index 000..0da500e
--- /dev/null
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -0,0 +1,640 @@
+/*
+ * Copyright 2009-2015 Freescale Semiconductor, Inc. and others
+ *
+ * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver.
+ * Jason ported to M54418TWR and MVFA5 (VF610).
+ * Authors: Stefan Agner 
+ *  Bill Pringlemeir 
+ *  Shaohui Xie 
+ *  Jason Jin 
+ *
+ * Based on original driver mpc5121_nfc.c.
+ *
+ * This 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.
+ *
+ * Limitations:
+ * - Untested on MPC5125 and M54418.
+ * - DMA not used.
+ * - 2K pages or less.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineDRV_NAME"vf610_nfc"
+
+/* Register Offsets */
+#define NFC_FLASH_CMD1 0x3F00
+#define NFC_FLASH_CMD2 0x3F04
+#define NFC_COL_ADDR   0x3F08
+#define NFC_ROW_ADDR   0x

[PATCH v7 3/5] mtd: nand: vf610_nfc: add device tree bindings

2015-07-24 Thread Stefan Agner
Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 .../devicetree/bindings/mtd/vf610-nfc.txt  | 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt

diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt 
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..cae5f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,45 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to "fsl,vf610-nfc"
+- reg: address range of the NFC
+- interrupts: interrupt of the NFC
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+
+Example:
+
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x400e 0x4000>;
+   interrupts = ;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-strength = <32>;
+   nand-ecc-step-size = <2048>;
+   nand-on-flash-bbt;
+   };
-- 
2.4.5

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


[PATCH v7 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

2015-07-24 Thread Stefan Agner
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf610-twr.dts | 44 +
 arch/arm/boot/dts/vfxxx.dtsi|  8 
 2 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..0b2b932 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -287,6 +287,50 @@
status = "okay";
 };
 
+&iomuxc {
+   vf610-twr {
+   pinctrl_nfc_1: nfcgrp_1 {
+   fsl,pins = <
+   VF610_PAD_PTD31__NF_IO150x28df
+   VF610_PAD_PTD30__NF_IO140x28df
+   VF610_PAD_PTD29__NF_IO130x28df
+   VF610_PAD_PTD28__NF_IO120x28df
+   VF610_PAD_PTD27__NF_IO110x28df
+   VF610_PAD_PTD26__NF_IO100x28df
+   VF610_PAD_PTD25__NF_IO9 0x28df
+   VF610_PAD_PTD24__NF_IO8 0x28df
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+   };
+};
+
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <16>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <24>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc_1>;
+   status = "okay";
+};
+
 &uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..2f4b04d 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,14 @@
status = "disabled";
};
 
+   nfc: nand@400e {
+   compatible = "fsl,vf610-nfc";
+   reg = <0x400e 0x4000>;
+   interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_NFC>;
+   clock-names = "nfc";
+   status = "disabled";
+   };
};
};
 };
-- 
2.4.5

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


[PATCH v7 5/5] ARM: dts: vf-colibri: enable NAND flash controller

2015-07-24 Thread Stefan Agner
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..8d7986a 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,19 @@
pinctrl-0 = <&pinctrl_i2c0>;
 };
 
+&nfc {
+   assigned-clocks = <&clks VF610_CLK_NFC>;
+   assigned-clock-rates = <3300>;
+   nand-bus-width = <8>;
+   nand-ecc-mode = "hw";
+   nand-ecc-step-size = <2048>;
+   nand-ecc-strength = <32>;
+   nand-on-flash-bbt;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_nfc_1>;
+   status = "okay";
+};
+
 &pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -156,6 +169,25 @@
>;
};
 
+   pinctrl_nfc_1: nfcgrp_1 {
+   fsl,pins = <
+   VF610_PAD_PTD23__NF_IO7 0x28df
+   VF610_PAD_PTD22__NF_IO6 0x28df
+   VF610_PAD_PTD21__NF_IO5 0x28df
+   VF610_PAD_PTD20__NF_IO4 0x28df
+   VF610_PAD_PTD19__NF_IO3 0x28df
+   VF610_PAD_PTD18__NF_IO2 0x28df
+   VF610_PAD_PTD17__NF_IO1 0x28df
+   VF610_PAD_PTD16__NF_IO0 0x28df
+   VF610_PAD_PTB24__NF_WE_B0x28c2
+   VF610_PAD_PTB25__NF_CE0_B   0x28c2
+   VF610_PAD_PTB27__NF_RE_B0x28c2
+   VF610_PAD_PTC26__NF_RB_B0x283d
+   VF610_PAD_PTC27__NF_ALE 0x28c2
+   VF610_PAD_PTC28__NF_CLE 0x28c2
+   >;
+   };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
-- 
2.4.5

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


[PATCH v7 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support

2015-07-24 Thread Stefan Agner
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages). Raw writes writes
are possible through the common nand_write_page_raw implementation,
however raw reads are not possible since the hardware ECC mode need
to be enabled at command time.

Signed-off-by: Bill Pringlemeir 
Signed-off-by: Stefan Agner 
---
 drivers/mtd/nand/Kconfig |   6 +-
 drivers/mtd/nand/vf610_nfc.c | 201 ++-
 2 files changed, 204 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8550b14..e05f53c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -469,8 +469,10 @@ config MTD_NAND_VF610_NFC
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
 
 config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 0da500e..4d795a5 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,6 +19,8 @@
  * - Untested on MPC5125 and M54418.
  * - DMA not used.
  * - 2K pages or less.
+ * - Only 2K page w. 64+ OOB and hardware ECC.
+ * - Raw page reads not implemented when using ECC.
  */
 
 #include 
@@ -72,6 +74,8 @@
 
 /* NFC ECC mode define */
 #define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
 
 /*** Register Mask and bit definitions */
 
@@ -104,6 +108,8 @@
 #define STATUS_BYTE1_MASK  0x00FF
 
 /* NFC_FLASH_CONFIG Field */
+#define CONFIG_ECC_SRAM_ADDR_MASK  0x7FC0
+#define CONFIG_ECC_SRAM_ADDR_SHIFT 22
 #define CONFIG_ECC_SRAM_REQ_BIT(1<<21)
 #define CONFIG_DMA_REQ_BIT (1<<20)
 #define CONFIG_ECC_MODE_MASK   0x000E
@@ -122,6 +128,21 @@
 #define CMD_DONE_CLEAR_BIT (1<<18)
 #define IDLE_CLEAR_BIT (1<<17)
 
+/* ECC status placed at end of buffers. */
+#define ECC_SRAM_ADDR  ((PAGE_2K + 256 - 8) >> 3)
+#define ECC_STATUS_MASK0x80
+#define ECC_ERR_COUNT  0x3F
+
+/*
+ * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
+ * and +7 for big-endian SoCs.
+ */
+#ifdef __LITTLE_ENDIAN
+#define ECC_OFFSET 4
+#else
+#define ECC_OFFSET 7
+#endif
+
 struct vf610_nfc {
struct mtd_info mtd;
struct nand_chip chip;
@@ -136,10 +157,40 @@ struct vf610_nfc {
 #define ALT_BUF_STAT 2
 #define ALT_BUF_ONFI 3
struct clk *clk;
+   bool use_hw_ecc;
+   u32 ecc_mode;
 };
 
 #define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
 
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+   .eccbytes = 45,
+   .eccpos = {19, 20, 21, 22, 23,
+  24, 25, 26, 27, 28, 29, 30, 31,
+  32, 33, 34, 35, 36, 37, 38, 39,
+  40, 41, 42, 43, 44, 45, 46, 47,
+  48, 49, 50, 51, 52, 53, 54, 55,
+  56, 57, 58, 59, 60, 61, 62, 63},
+   .oobfree = {
+   {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+   .eccbytes = 60,
+   .eccpos = { 4,  5,  6,  7,  8,  9, 10, 11,
+  12, 13, 14, 15, 16, 17, 18, 19,
+  20, 21, 22, 23, 24, 25, 26, 27,
+  28, 29, 30, 31, 32, 33, 34, 35,
+  36, 37, 38, 39, 40, 41, 42, 43,
+  44, 45, 46, 47, 48, 49, 50, 51,
+  52, 53, 54, 55, 56, 57, 58, 59,
+  60, 61, 62, 63 },
+   .oobfree = {
+   {.offset = 2,
+.length = 2} }
+};
+
 static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
 {
return readl(nfc->regs + reg);
@@ -281,6 +332,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc, 
int column, int page)
ROW_ADDR_SHIFT, page);
 }
 
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+   vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+   CONFIG_ECC_MODE_MASK,
+   CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
 static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
 {
vf610_nfc_write(nfc, NFC_SECTOR_SIZE, size);
@@ -299,

[PATCH v7 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610

2015-07-24 Thread Stefan Agner
This seventh revision simplifies the config symbols somewhat, but
is otherwise just a rebase version on current l2-mtd/master.

I reran the MTD tests, they still all succeed.

Some more information and the full test log can be found in the
cover letter of the last revision v6:
http://thread.gmane.org/gmane.linux.kernel/1979868

Changes since v6:
- Rebased ontop of l2-mtd/master (v4.2-rc1 based)
- Removed HAVE_NAND_VF610_NFC and use depends on. This made
  "[PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller" unnecessary

Changes since v5:
- Removed fsl,mpc5125-nfc compatible string
- Removed readl/writel_relaxed
- Change interface of vf610_nfc_transfer_size to match other accessors

Changes since v4:
- Rebased ontop of l2-mtd/master (v4.1-rc4 based)
- Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does
  not support sub-page writes anyway (improves write performance)
- Support ONFI by enabling READID command with offset and parameter page
  reads (CMD_PARAM)
- Change to dedicated read_page/write_page function, enables raw writes
- Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements
- Eliminated vf610_nfc_probe_dt in favor of common DT init code
- Use wait_for_completion_timeout
- Some style fixes (spaces, etc.)

Changes since v3:
- Make the driver selectable when COMPILE_TEST is set
- Fix compile error due to superfluous ECC_STATUS configuration in initial
  patch (without ECC correction ECC_STATUS does not need to be configured)
- Remove custom BBT pattern and switch to in-band BBT in the initial patch
- Include two bug fixes, for details see the corresponding U-Boot patches:
  http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802

Changes since v2:
- Updated binding documentation

Changes since v1:
- Nest nfc_config struct within the main nfc struct
- Use assigned clock binding to specify NFC clock
- Rebased ontop of MSCM IR patchset (driver parts have been merged)
- Split out arch Kconfig in a separate config
- Fix module license
- Updated MAINTAINERS

Changes since RFC (Bill Pringlemeir):
- Renamed driver from fsl_nfc to vf610_nfc
- Use readl/writel for all register in accessor functions
- Optimized field accessor functions
- Implemented PM (suspend/resume) functions
- Implemented basic support for ECC strength/ECC step size from dt
- Improved performance of count_written_bits by using hweight32
- Support ECC with 60-bytes to correct up to 32 bit errors
- Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes
  which uses up to 60 bytes on 64 byte OOB
- Removed custom (downstream) BBT pattern since BBT table won't be
  compatible anyway (due to the change above)

Stefan Agner (5):
  mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
  mtd: nand: vf610_nfc: add hardware BCH-ECC support
  mtd: nand: vf610_nfc: add device tree bindings
  ARM: dts: vf610twr: add NAND flash controller peripherial
  ARM: dts: vf-colibri: enable NAND flash controller

 .../devicetree/bindings/mtd/vf610-nfc.txt  |  45 ++
 MAINTAINERS|   6 +
 arch/arm/boot/dts/vf-colibri.dtsi  |  32 +
 arch/arm/boot/dts/vf610-twr.dts|  44 ++
 arch/arm/boot/dts/vfxxx.dtsi   |   8 +
 drivers/mtd/nand/Kconfig   |  11 +
 drivers/mtd/nand/Makefile  |   1 +
 drivers/mtd/nand/vf610_nfc.c   | 839 +
 8 files changed, 986 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
 create mode 100644 drivers/mtd/nand/vf610_nfc.c

-- 
2.4.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-07-21 Thread Stefan Agner
Hi Dmitry,

As the original author of the driver I have some remarks to your review

On 2015-07-18 01:42, Dmitry Torokhov wrote:
>> +/*
>> + * If touch pressure is too low, stop measuring and reenable
>> + * touch detection
>> + */
>> +if (val_p < min_pressure || val_p > 2000)
>> +break;

This is where the modules touch pressure is used to stop the measurement
process and switch back to interrupt mode. See my remarks at the end.

>> +
>> +/*
>> + * The pressure may not be enough for the first x and the
>> + * second y measurement, but, the pressure is ok when the
>> + * driver is doing the third and fourth measurement. To
>> + * take care of this, we drop the first measurement always.
>> + */
>> +if (discard_val_on_start) {
>> +discard_val_on_start = false;
>> +} else {
>> +/*
>> + * Report touch position and sleep for
>> + * next measurement
>> + */
>> +input_report_abs(vf50_ts->ts_input,
>> +ABS_X, VF_ADC_MAX - val_x);
>> +input_report_abs(vf50_ts->ts_input,
>> +ABS_Y, VF_ADC_MAX - val_y);
>> +input_report_abs(vf50_ts->ts_input,
>> +ABS_PRESSURE, val_p);
>> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 1);
>> +input_sync(vf50_ts->ts_input);
>> +}
>> +
>> +msleep(10);
>> +}
>> +
>> +/* Report no more touch, reenable touch detection */
>> +input_report_abs(vf50_ts->ts_input, ABS_PRESSURE, 0);
>> +input_report_key(vf50_ts->ts_input, BTN_TOUCH, 0);
>> +input_sync(vf50_ts->ts_input);
>> +
>> +vf50_ts_enable_touch_detection(vf50_ts);
>> +
>> +/* Wait for the pull-up to be stable on high */
>> +msleep(10);
>> +
>> +/* Reenable IRQ to detect touch */
>> +enable_irq(vf50_ts->pen_irq);
>> +
>> +dev_dbg(dev, "Reenabled touch detection interrupt\n");
>> +}
>> +
>> +static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
>> +{
>> +struct vf50_touch_device *vf50_ts = (struct vf50_touch_device *)dev_id;
>> +struct device *dev = &vf50_ts->pdev->dev;
>> +
>> +dev_dbg(dev, "Touch detected, start worker thread\n");
>> +
>> +disable_irq_nosync(irq);
>> +
>> +/* Disable the touch detection plates */
>> +gpiod_set_value(vf50_ts->gpio_ym, 0);
>> +
>> +/* Let the platform mux to default state in order to mux as ADC */
>> +pinctrl_pm_select_default_state(dev);
>> +
>> +queue_work(vf50_ts->ts_workqueue, &vf50_ts->ts_work);
> 
> If you convert this to a threaded interrupt you won't need to
> disable/reenable interrupt or queue work. You should also be able to use
> gpiod_set_value_cansleep() extending the range of ways the controller
> could be connected to systems.
> 

I'm not sure if a threaded interrupt is the right thing here. While the
pen is on the touchscreen (which can be for several seconds)
measurements have to be made in a continuous loop. Is it ok for a
threaded interrupt to run that long?

I'm also not sure if it is really safe to _not_ disable the pen down
GPIO interrupt. If we get a interrupt while measuring, we should ignore
that interrupt.

On resistive touch screens the pen down works by relying on the high
resistance between the two plates while not being touched. The X-Plate
will be pulled high, the Y-Plate is strong GND. We measure on the
X-Plate (XM) which is high too. As soon as the plate is touched, XM will
be GND (since the resistance over the two plates is way lower then the
pull-up resistance). An interrupt on falling edge will trigger.

Now the measuring takes place, X, Y and pressure by using different
measuring methods.

While Y-Plate measurement the same GPIO interupt pin is used for ADC
measurement! The voltage on that pin will at that point depend on the
Y-Position of the pen position... Is it guaranteed that the GPIO
interrupt is not fired? I guess because we muxed to ADC at that point,
it won't lead to a second (spurious) interrupt... However this is a
thing which needs to be checked before removing interrupt enable/disable
calls.

>> +};
>> +
>> +module_platform_driver(vf50_touch_driver);
>> +
>> +module_param(min_pressure, int, 0600);
>> +MODULE_PARM_DESC(min_pressure, "Minimum pressure for touch detection");
> 
> I'd rather let userspace figure out what it recognizes as valid touch.
> 

This is value is used as the termination condition for the measurement
loop. It essentially defines at which pressure level we stop measuring
X/Y values. Depending on the size and resistance of the plates. However,
it is not safe to measure even at low/no pressure, since then we would
only get maximum X/Y values. Hence it is cruci

[PATCH v2] ARM: dts: vf-colibri: define stdout-path property

2015-07-15 Thread Stefan Agner
Define Vybrid's UART0, connected to the Colibri pinout UART_A, as
standard output.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi 
b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index 77e1a45..2ce6fe5 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -9,7 +9,7 @@
 
 / {
chosen {
-   bootargs = "console=ttyLP0,115200";
+   stdout-path = "serial0:115200n8";
};
 
clk16m: clk16m {
-- 
2.4.5

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


Re: [PATCH] ARM: dts: vf-colibri: define stdout-path property

2015-07-15 Thread Stefan Agner
On 2015-07-13 17:10, Shawn Guo wrote:
> On Fri, Jul 03, 2015 at 10:06:39AM +0200, Stefan Agner wrote:
>> Define Vybrid's UART0, connected to the Colibri pinout UART_A, as
>> standard output.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>>  arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi 
>> b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
>> index 2cbe663..cb199ae 100644
>> --- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
>> +++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
>> @@ -10,6 +10,7 @@
>>  / {
>>  chosen {
>>  bootargs = "console=ttyLP0,115200";
>> +stdout-path = "serial0:115200n8";
> 
> With this change, can bootargs just be dropped?

I guess it would break a (fairly old) kernel which does not support
stdout-path yet?

However, the newer Vybrid DT's anyway do not work on old kernels due to
the interrupt hierarchy changes...

Will send a v2 without default bootargs.

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


Re: [PATCH v3 2/2] ARM: dts: vf-colibri: Add property for minimum sample time

2015-07-15 Thread Stefan Agner
On 2015-07-15 03:57, Shawn Guo wrote:
> On Tue, Jul 14, 2015 at 07:23:23PM +0530, Sanchayan Maity wrote:
>> Add a device tree property which allows to specify the minimum sample
>> time which can be used to calculate the actual ADC cycles required
>> depending on the hardware.
>>
>> Signed-off-by: Sanchayan Maity 
>> ---
>>  arch/arm/boot/dts/vf-colibri.dtsi | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/vf-colibri.dtsi 
>> b/arch/arm/boot/dts/vf-colibri.dtsi
>> index ab10d2e..59f5deb 100644
>> --- a/arch/arm/boot/dts/vf-colibri.dtsi
>> +++ b/arch/arm/boot/dts/vf-colibri.dtsi
>> @@ -16,10 +16,12 @@
>>  };
>>
>>  &adc0 {
>> +min-sample-time = <1000>;
>>  status = "okay";
>>  };
>>
>>  &adc1 {
>> +min-sample-time = <1000>;
> 
> Since this is the default value anyway, we can just save the patch,
> right?

I thought it would be nice to be explicit here and define this value
which we verified internally.

On the other hand, we did not derived the minimum value from the DS
(using the capacity/resistance of the actual analog source connected) to
maximize the sampling frequency, hence I'm also ok with not explicitly
defining a value.

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/2] ARM: dts: vfxxx: Add property for minimum sample time

2015-07-12 Thread Stefan Agner
On 2015-07-12 08:47, maitysancha...@gmail.com wrote:
> Hello Jonathan,
> 
> On 15-07-11 18:39:10, Jonathan Cameron wrote:
>> On 10/07/15 19:06, maitysancha...@gmail.com wrote:
>> > Hello Shawn,
>> >
>> > On 15-07-10 16:53:24, Shawn Guo wrote:
>> >> On Wed, Jun 24, 2015 at 02:03:41PM +0530, Sanchayan Maity wrote:
>> >>> Add a device tree property which allows to specify the minimum sample
>> >>> time which can be used to calculate the actual ADC cycles required
>> >>> depending on the hardware.
>> >>>
>> >>> Signed-off-by: Sanchayan Maity 
>> >>> ---
>> >>>  arch/arm/boot/dts/vfxxx.dtsi | 2 ++
>> >>>  1 file changed, 2 insertions(+)
>> >>>
>> >>> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
>> >>> index 90a03d5..71d9c08 100644
>> >>> --- a/arch/arm/boot/dts/vfxxx.dtsi
>> >>> +++ b/arch/arm/boot/dts/vfxxx.dtsi
>> >>> @@ -229,6 +229,7 @@
>> >>>  status = "disabled";
>> >>>  fsl,adck-max-frequency = <3000>, 
>> >>> <4000>,
>> >>>  <2000>;
>> >>> +min-sample-time = <1000>;
>> >>>  };
>> >>>
>> >>>  wdoga5: wdog@4003e000 {
>> >>> @@ -447,6 +448,7 @@
>> >>>  status = "disabled";
>> >>>  fsl,adck-max-frequency = <3000>, 
>> >>> <4000>,
>> >>>  <2000>;
>> >>> +min-sample-time = <1000>;
>> >>
>> >> Can we code 1000 as the default in kernel driver, so that only boards
>> >> requiring different value need to have this property?  Doing so makes
>> >> the property optional rather than required.
>> >>
>> >
>> > Not sure if hardcoding it in the driver is the right approach.
>> If it is a true feature of the device (i.e. if in the case of perfect
>> front end electronics) this is the right option, then a default makes
>> a lot of sense.  If that isn't the case (I suspect not) then if we
>> drop it be optional chances are no one will bother thinking about it
>> or trying to tune this at all.
>>
>> Hence seems wrong to put a fairly arbitrary default value on it.
>> However, we do need to still work with old device trees and new kernels
>> so need to cope without it.
>>
>> Hence to my mind, if we had started out with this in the first driver
>> version, then the default would be a bad idea.  As we didn't then we
>> really need to cope with nothing specified (as best we can) and so
>> we do need a sensible default (or perhaps even sensible worst
>> case default) in there.

I agree with Jonathan's argumentation, let's add a default if the dt
propery is not there.

1000ns seems to be a good default value over a wide range of external
resistance/capacity according to the diagrams of the data sheet, so I
would vote for that value as default.

> 
> Just to be sure, do I understand you correctly that you agree with the
> property being in device tree?

I don't think that the device tree property is in discussion, it is just
about whether to add a default value in the driver or not...

> 
> If the device tree property is not specified the driver will just go on
> to use the value "3" which was hardcoded earlier. In my opinion it is
> better to allow users to change the sampling cycles by specifying or not
> specifying this in the device tree rather than have a default value coded
> in the driver. However this is just my opinion.
> 
> Also, some users might not need the somewhat worst case value of 1000. I
> guess we could keep the driver patch the way it is right now and migrate
> the property to be specified in our board dts file? So the property can
> be picked up from the vf-colibri.dtsi or vf500-colibri.dtsi in the adc
> node? Other boards can do the same?

I agree too, especially when we have a default value in the driver, the
property belongs into the board file. I suggest to add the default value
of 1000 to the vf-colibri.dtsi (even if this is the driver default, so
we explicitly request that "verified" value..)

--
Stefan

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


Re: [PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller

2015-07-09 Thread Stefan Agner
On 2015-07-09 03:55, Shawn Guo wrote:
> On Wed, Jul 08, 2015 at 10:32:54AM -0400, Bill Pringlemeir wrote:
>>
>> On  8 Jul 2015, shawn...@kernel.org wrote:
>> > On Fri, Jun 19, 2015 at 12:58:37AM +0200, Stefan Agner wrote:
>> >> Enable the NAND Flash Controller driver which is part of the Vybrid
>> >> SoC by default.
>> >>
>> >> Signed-off-by: Stefan Agner 
>> >> ---
>> >> arch/arm/mach-imx/Kconfig | 1 +
>> >> 1 file changed, 1 insertion(+)
>> >>
>> >> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
>> >> index 3a3d3e9..9358135 100644
>> >> --- a/arch/arm/mach-imx/Kconfig
>> >> +++ b/arch/arm/mach-imx/Kconfig
>> >>>> -589,6 +589,7 @@ config SOC_VF610
>> >>   select PINCTRL_VF610
>> >>   select PL310_ERRATA_769419 if CACHE_L2X0
>> >>   select SMP_ON_UP if SMP
>> >> + select HAVE_NAND_VF610_NFC
>>
>> > I'm not sure about the benefit of having this option, except we have
>> > to have this additional architecture patch.
>>
>> For other SOC, like the PowerPC or ColdFire CPUs with this controller,
>> it was a way to mark the controller as populated.  Otherwise, the
>> Kconfig entry to select the controller will pop up for everybody.
> 
> IMHO, having the option pop up for everybody isn't really a problem.  On
> the other hand, we can even compile test the driver on any architecture
> without the COMPILE_TEST dependency.

I think the distro people don't like that too much. Afaik they enable
all drivers as modules, and hence the NAND driver would end up as kernel
module in x86 distros... 

Reminds me that I wanted to send a patch to add the dependencies of
STE_MODEM_RPROC, I recently stumbled upon the remoteproc/ste_modem_rproc
kernel modules on my distro, which both are actually not really useful
on x86 :-)


> But if MTD maintainer has a different opinion, we can still have a
> 'depends on SOC_VF610' to save this patch.

I think this is the better solution, and Sebastian suggested that too. I
will implement that in the next patch revision...

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/1] ARM: dts: vfxxx: Include support for esdhc0 functionality.

2015-07-09 Thread Stefan Agner
On 2015-07-08 22:51, Cory Tusar wrote:
> Extend the existing Vybrid eSDHC devicetree implementation to also
> describe the esdhc0 functional block.
> 
> Tested on a custom VF610-based board with a Toshiba THGBM1G5D2EBAI7 eMMC
> module attached to esdhc0.
> 
> Signed-off-by: Cory Tusar 

Looks good to me:
Acked-by: Stefan Agner 

> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 4aa3351..7e97017 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -445,6 +445,17 @@
>   status = "disabled";
>   };
>  
> + esdhc0: esdhc@400b1000 {
> + compatible = "fsl,imx53-esdhc";
> + reg = <0x400b1000 0x1000>;
> + interrupts = <27 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_IPG_BUS>,
> + <&clks VF610_CLK_PLATFORM_BUS>,
> + <&clks VF610_CLK_ESDHC0>;
> + clock-names = "ipg", "ahb", "per";
> + status = "disabled";
> + };
> +
>   esdhc1: esdhc@400b2000 {
>   compatible = "fsl,imx53-esdhc";
>   reg = <0x400b2000 0x1000>;

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


Re: [PATCH 0/1] Add support for esdhc0 on Vybrid.

2015-07-08 Thread Stefan Agner
On 2015-07-09 08:07, Holger Schurig wrote:
>> Cory Tusar (1):
>>   ARM: dts: vfxxx: Include support for esdhc0 functionality.
>>
>>  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> --
>> 2.3.6
> 
> Your patch looks empty.

This is a cover letter which provides overview over a whole patchset.
The patch is a separate reply message of this mail (PATCH 1/1). 

@Cory
However, it is unusual to use a cover letter when there is only a single
patch. If you want to add additional comments which should not be part
of the commit message, you can edit the patch and insert text after the
three dashes, just before the diffstat. This text won't be part of the
commit when applied later.

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/2] iio: adc: Determine sampling frequencies by using minimum sample time

2015-07-06 Thread Stefan Agner
On 2015-06-24 10:33, Sanchayan Maity wrote:
> The driver currently does not take into account the minimum sample time
> as per the Figure 6-8 Chapter 9.1.1 12-bit ADC electrical characteristics.
> We set a static amount of cycles instead of considering the sample time
> as a given value, which depends on hardware characteristics.
> 
> Determine sampling frequencies by first reading the device tree property
> node and then calculating the required Long Sample Time Adder (LSTAdder)
> value based on the ADC clock frequency and sample time value obtained
> from the device tree, this LSTAdder value is then used for calculating
> the sampling frequencies possible.
> 
> Signed-off-by: Sanchayan Maity 

Not respecting the sampling time leads to issues especially when using
multiple channel: You basically still have some capacity from the last
measurement, which distorts the next measurements. We noticed this when
using the touch screen while measuring the SoC temperature.

The required sampling time is partly given by the SoC, but depends on
the connected analog source too. A device tree property is the right
approach here.

Acked-by: Stefan Agner 


> ---
>  .../devicetree/bindings/iio/adc/vf610-adc.txt  |  6 ++
>  drivers/iio/adc/vf610_adc.c| 74 
> --
>  2 files changed, 76 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
> b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
> index 3eb40e2..39b86ea 100644
> --- a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
> @@ -17,6 +17,11 @@ Recommended properties:
>- Frequency in normal mode (ADLPC=0, ADHSC=0)
>- Frequency in high-speed mode (ADLPC=0, ADHSC=1)
>- Frequency in low-power mode (ADLPC=1, ADHSC=0)
> +  - min-sample-time: Minimum sampling time in nanoseconds. This value has
> +to be chosen according to the conversion mode and the connected analog
> +  source resistance (R_as) and capacitance (C_as). Refer the datasheet's
> +  operating requirements. A safe default across a wide range of R_as and
> +  C_as as well as conversion modes is 1000ns.
>  
>  Example:
>  adc0: adc@4003b000 {
> @@ -27,5 +32,6 @@ adc0: adc@4003b000 {
>   clock-names = "adc";
>   fsl,adck-max-frequency = <3000>, <4000>,
>   <2000>;
> + min-sample-time = <1000>;
>   vref-supply = <®_vcc_3v3_mcu>;
>  };
> diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> index 480f335..8322027 100644
> --- a/drivers/iio/adc/vf610_adc.c
> +++ b/drivers/iio/adc/vf610_adc.c
> @@ -68,6 +68,9 @@
>  #define VF610_ADC_CLK_DIV8   0x60
>  #define VF610_ADC_CLK_MASK   0x60
>  #define VF610_ADC_ADLSMP_LONG0x10
> +#define VF610_ADC_ADSTS_SHORT   0x100
> +#define VF610_ADC_ADSTS_NORMAL  0x200
> +#define VF610_ADC_ADSTS_LONG0x300
>  #define VF610_ADC_ADSTS_MASK 0x300
>  #define VF610_ADC_ADLPC_EN   0x80
>  #define VF610_ADC_ADHSC_EN   0x400
> @@ -124,6 +127,17 @@ enum conversion_mode_sel {
>   VF610_ADC_CONV_LOW_POWER,
>  };
>  
> +enum lst_adder_sel {
> + VF610_ADCK_CYCLES_3,
> + VF610_ADCK_CYCLES_5,
> + VF610_ADCK_CYCLES_7,
> + VF610_ADCK_CYCLES_9,
> + VF610_ADCK_CYCLES_13,
> + VF610_ADCK_CYCLES_17,
> + VF610_ADCK_CYCLES_21,
> + VF610_ADCK_CYCLES_25,
> +};
> +
>  struct vf610_adc_feature {
>   enum clk_selclk_sel;
>   enum vol_refvol_ref;
> @@ -132,6 +146,8 @@ struct vf610_adc_feature {
>   int clk_div;
>   int sample_rate;
>   int res_mode;
> + u32 lst_adder_index;
> + u32 default_sample_time;
>  
>   boolcalibration;
>   boolovwren;
> @@ -155,11 +171,13 @@ struct vf610_adc {
>  };
>  
>  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
> +static const u32 vf610_lst_adder[] = { 3, 5, 7, 9, 13, 17, 21, 25 };
>  
>  static inline void vf610_adc_calculate_rates(struct vf610_adc *info)
>  {
>   struct vf610_adc_feature *adc_feature = &info->adc_feature;
>   unsigned long adck_rate, ipg_rate = clk_get_rate(info->clk);
> + u32 adck_period, lst_addr_min;
>   int divisor, i;
>  
>   adck_rate = info->max_adck_rate[adc_feature->conv_mode];
> @@ -174,6 +192,19 @@ static inline void
> vf610_adc_calculate_rates(struct vf610_adc *info)
>   }
>  
>   /*
> +  * Determine the long sample time adder value to be used based
> +  * on the 

Re: [PATCH v1 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50

2015-07-03 Thread Stefan Agner
Hi Sanchayan,

I wrote the driver some while ago, so reading it today again feels like
reading someone else's code again :-)

Some minor nits below:

On 2015-06-30 08:54, Sanchayan Maity wrote:
> The Colibri Vybrid VF50 module supports 4-wire touchscreens using
> FETs and ADC inputs. This driver uses the IIO consumer interface
> and relies on the vf610_adc driver based on the IIO framework.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  drivers/input/touchscreen/Kconfig   |  12 +
>  drivers/input/touchscreen/Makefile  |   1 +
>  drivers/input/touchscreen/colibri-vf50-ts.c | 466 
> 
>  3 files changed, 479 insertions(+)
>  create mode 100644 drivers/input/touchscreen/colibri-vf50-ts.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index 80f6386..c243914 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -1027,4 +1027,16 @@ config TOUCHSCREEN_ZFORCE
> To compile this driver as a module, choose M here: the
> module will be called zforce_ts.
>  
> +config TOUCHSCREEN_COLIBRI_VF50
> + tristate "Toradex Colibri on board touchscreen driver"
> + depends on IIO && VF610_ADC

Since we use GPIO's this also depends on GPIOLIB

> + help
> +   Say Y here if you have a Colibri VF50 and plan to use
> +   the on-board provided 4-wire touchscreen driver.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called colibri_vf50_ts.
> +

> +
> + /* Use hrtimer sleep since msleep sleeps 10ms+ */

This comment is probably somewhat outdated. Depending on kernel
configuration probably wrong too. Just drop it.

> + usleep_range(COLI_TOUCH_MIN_DELAY_US, COLI_TOUCH_MAX_DELAY_US);
> +
> + for (i = 0; i < 5; i++) {
> + ret = iio_read_channel_raw(channel, &val);
> + if (ret < 0)
> + return -EINVAL;
> +
> + value += val;
> + }
> +
> + value /= 5;
> +
> + gpiod_set_value(plate_p, 0);
> + gpiod_set_value(plate_m, 0);
> +
> + return value;
> +}
> +
> +/*
> + * Enable touch detection using falling edge detection on XM
> + */
> +static void vf50_ts_enable_touch_detection(struct vf50_touch_device *vf50_ts)
> +{
> + /* Enable plate YM (needs to be strong GND, high active) */
> + gpiod_set_value(vf50_ts->gpio_ym, 1);
> +
> + /* Let the platform mux to GPIO in order to enable Pull-Up on GPIO */

The comment is somewhat configuing, since you use the pinctrl framework
to mux to the state "idle" I would write "Let the platform mux to
idle..."

> + pinctrl_pm_select_idle_state(&vf50_ts->pdev->dev);
> +}
> +
> +/*
> + * ADC touch screen sampling worker function
> + */
> +static void vf50_ts_work(struct work_struct *ts_work)
> +{
> + struct vf50_touch_device *vf50_ts = container_of(ts_work,
> + struct vf50_touch_device, ts_work);
> + struct device *dev = &vf50_ts->pdev->dev;
> + int val_x, val_y, val_z1, val_z2, val_p = 0;
> + bool discard_val_on_start = true;
> +
> + while (!vf50_ts->stop_touchscreen) {
> + /* X-Direction */
> + val_x = adc_ts_measure(&vf50_ts->channels[0],
> + vf50_ts->gpio_xp, vf50_ts->gpio_xm);
> + if (val_x < 0)
> + continue;
> +
> + /* Y-Direction */
> + val_y = adc_ts_measure(&vf50_ts->channels[1],
> + vf50_ts->gpio_yp, vf50_ts->gpio_ym);
> + if (val_y < 0)
> + continue;
> +
> + /*
> +  * Touch pressure
> +  * Measure on XP/YM
> +  */
> + val_z1 = adc_ts_measure(&vf50_ts->channels[2],
> + vf50_ts->gpio_yp, vf50_ts->gpio_xm);
> + if (val_z1 < 0)
> + continue;
> + val_z2 = adc_ts_measure(&vf50_ts->channels[3],
> + vf50_ts->gpio_yp, vf50_ts->gpio_xm);
> + if (val_z2 < 0)
> + continue;
> +
> + /*
> +  * According to datasheet of our touchscreen,
> +  * resistance on X axis is 400~1200..
> +  */

This is somewhat vague and not really helpful, either mention the type
(I think it was an EDT) or drop that...

> +
> + /* Validate signal (avoid calculation using noise) */
> + if (val_z1 > 64 && val_x > 64) {
> + /*
> +  * Calculate resistance between the plates
> +  * lower resistance means higher pressure
> +  */
> + int r_x = (1000 * val_x) / VF_ADC_MAX;
> +
> + val_p = (r_x * val_z2) / val_z1 - r_x;
> +
> + } else {
> + val_p = 2000;
> + }
> +
> + val_p

Re: [PATCH v1 2/4] ARM: dts: vf500-colibri: Add device tree node for touchscreen support

2015-07-03 Thread Stefan Agner
On 2015-06-30 08:54, Sanchayan Maity wrote:
> Add device tree node for touchscreen support on Colibri VF50. The
> touchscreen functionality on VF50 uses the ADC channels of Vybrid
> and some GPIOs. Also add pinctrl nodes for proper pinmux.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vf500-colibri-eval-v3.dts |  4 +++
>  arch/arm/boot/dts/vf500-colibri.dtsi| 46 
> +
>  2 files changed, 50 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> index 7fc782c..c5efb57 100644
> --- a/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> +++ b/arch/arm/boot/dts/vf500-colibri-eval-v3.dts
> @@ -15,3 +15,7 @@
>   model = "Toradex Colibri VF50 on Colibri Evaluation Board";
>   compatible = "toradex,vf500-colibri_vf50-on-eval",
> "toradex,vf500-colibri_vf50", "fsl,vf500";
>  };
> +
> +&touchctrl {
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/vf500-colibri.dtsi
> b/arch/arm/boot/dts/vf500-colibri.dtsi
> index cee34a3..4807a32 100644
> --- a/arch/arm/boot/dts/vf500-colibri.dtsi
> +++ b/arch/arm/boot/dts/vf500-colibri.dtsi
> @@ -17,4 +17,50 @@
>   memory {
>   reg = <0x8000 0x800>;
>   };
> +
> + touchctrl: vf50_touchctrl {
> + compatible = "toradex,vf50-touchctrl";
> + io-channels = <&adc1 0>,<&adc0 0>,
> + <&adc0 1>,<&adc1 2>;
> + xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
> + xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
> + yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
> + pen-detect-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
> + pen-pullup-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "idle","default","gpios";
> + pinctrl-0 = <&pinctrl_touchctrl_idle>;
> + pinctrl-1 = <&pinctrl_touchctrl_default>;
> + pinctrl-2 = <&pinctrl_touchctrl_gpios>;
> + status = "disabled";
> + };
> +};
> +
> +&iomuxc {
> + vf610-colibri {
> + pinctrl_touchctrl_idle: touchctrl_idle {
> + fsl,pins = <
> + VF610_PAD_PTA18__GPIO_8 0x206d

I think the detect pin should be in Hi-Z, not be pulled up. Probably the
resistance over the plates is much smaller on pen down, hence it doesn't
matter too much.

> + VF610_PAD_PTA19__GPIO_9 0x206d
> + >;
> + };
> +
> + pinctrl_touchctrl_default: touchctrl_default {
> + fsl,pins = <
> + VF610_PAD_PTA18__ADC0_SE0   0x2060
> + VF610_PAD_PTA19__ADC0_SE1   0x2060
> + VF610_PAD_PTA16__ADC1_SE0   0x2060
> + VF610_PAD_PTB2__ADC1_SE20x2060
> + >;
> + };
> +
> + pinctrl_touchctrl_gpios: touchctrl_gpios {
> + fsl,pins = <
> + VF610_PAD_PTA23__GPIO_130x22ed
> + VF610_PAD_PTB23__GPIO_930x22ed
> + VF610_PAD_PTA22__GPIO_120x22ed
> + VF610_PAD_PTA11__GPIO_4 0x22ed
> + >;
> + };

Hm, those have pull-ups on too, since you set them as output in the
drivers open function, I don't think this is necessary.

> + };
>  };

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


Re: [PATCH v1 1/4] ARM: dts: vfxxx: Add io-channel-cells property for ADC node

2015-07-03 Thread Stefan Agner
On 2015-06-30 08:54, Sanchayan Maity wrote:
> This commit adds io-channel-cells property to the ADC node. This
> property is required in order for an IIO consumer driver to work.
> Especially required for Colibri VF50, as the touchscreen driver
> uses ADC channels with the ADC driver based on IIO framework.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 2c20f3f..f7d8fb6 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -227,6 +227,7 @@
>   clocks = <&clks VF610_CLK_ADC0>;
>   clock-names = "adc";
>   status = "disabled";
> + #io-channel-cells = <1>;
>   };
>  
>   tcon0: tcon@4003d000 {
> @@ -461,6 +462,7 @@
>   clocks = <&clks VF610_CLK_ADC1>;
>   clock-names = "adc";
>   status = "disabled";
> + #io-channel-cells = <1>;
>   };
>  
>   esdhc1: esdhc@400b2000 {

Minor nitpick: can you put the new property one line up? That way it
would be sorted alphabetically and status is conveniently still at the
end.

Otherwise:

Acked-by: Stefan Agner 

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: vf-colibri: define stdout-path property

2015-07-03 Thread Stefan Agner
Define Vybrid's UART0, connected to the Colibri pinout UART_A, as
standard output.

Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi 
b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
index 2cbe663..cb199ae 100644
--- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
@@ -10,6 +10,7 @@
 / {
chosen {
bootargs = "console=ttyLP0,115200";
+   stdout-path = "serial0:115200n8";
};
 
clk16m: clk16m {
-- 
2.4.4

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


Re: [RFC PATCH 2/7] ARM: dts: vfxxx: Include support for qspi1 functionality.

2015-07-02 Thread Stefan Agner
On 2015-07-01 22:20, Cory Tusar wrote:
> This commit extends the existing Vybrid QSPI devicetree implementation
> to also describe the qspi1 functional block.
> 
> Signed-off-by: Cory Tusar 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 089a263..a7c370e 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -251,6 +251,19 @@
>   status = "disabled";
>   };
>  
> + qspi1: quadspi@400c4000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-qspi";
> + reg = <0x400c4000 0x1000>, <0x5000 
> 0x1000>;
> + reg-names = "QuadSPI", "QuadSPI-memory";
> + interrupts = <25 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_QSPI1_EN>,
> + <&clks VF610_CLK_QSPI1>;
> + clock-names = "qspi_en", "qspi";
> + status = "disabled";
> + };
> +
>   iomuxc: iomuxc@40048000 {
>   compatible = "fsl,vf610-iomuxc";
>   reg = <0x40048000 0x1000>;

This seem to be at the wrong place under aips0. qspi1 should be under
aips1. just before fec0. But other than that, I checked the addresses
looks good to me. Hence with that change applied you can include:

Reviewed-by: Stefan Agner 

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


Re: [RFC PATCH 1/7] ARM: dts: vf610: Add missing QuadSPI register mapping and names.

2015-07-02 Thread Stefan Agner
On 2015-07-01 22:20, Cory Tusar wrote:
> Both 'reg' and 'reg-names' are required properties according to binding
> documentation, and both should contain two items.
> 
> Signed-off-by: Cory Tusar 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 4aa3351..089a263 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -242,7 +242,8 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   compatible = "fsl,vf610-qspi";
> - reg = <0x40044000 0x1000>;
> + reg = <0x40044000 0x1000>, <0x2000 
> 0x1000>;
> + reg-names = "QuadSPI", "QuadSPI-memory";
>   interrupts = <24 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = <&clks VF610_CLK_QSPI0_EN>,
>   <&clks VF610_CLK_QSPI0>;

Hm, this seem to have been wrong since the beginning...

Acked-by: Stefan Agner 

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


  1   2   3   4   >