[PATCH v1 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[PATCH v1 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar,Vadivel MuruganX]

This patch adds the new IP of NAND Flash Controller support on Intel's
Lightning Mountain(LGM) SoC.

DMA is used for burst data transfer operation, also DMA HW supports
aligned 32bit memory address and aligned data access by default.
DMA burst of 8 supported,Data register used to support the read/write
operation from/to device.

The NAND controller Subsystem consisting of LGM + ECC-NAND controller supports:
NAND Flash Features :
-16/8-bit data bus
  Page + OOB Bytes
- 512  + (2 - 13) bytes per page page
- 2048 + (7 - 210) bytes per page
- 4096 + (13 - 420) bytes per page
- 8192 + (26 - 840) bytes per page

- Support 32/64/128/256/512/1024/2048/4096/8192/16384/32768 Mbytes flash device
- ECC calculation/generation and verification on-the-fly

Ramuthevar Vadivel Murugan (2):
  dt-bindings: mtd: Add YAML for Nand Flash Controller support
  mtd: rawnand: Add NAND controller support on Intel LGM SoC

 .../devicetree/bindings/mtd/intel,lgm-nand.yaml    |  61 ++
 drivers/mtd/nand/raw/Kconfig                       |   7 +
 drivers/mtd/nand/raw/Makefile                      |   1 +
 drivers/mtd/nand/raw/intel_lgm_nand.c              | 678 +++++++++++++++++++++
 4 files changed, 747 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
 create mode 100644 drivers/mtd/nand/raw/intel_lgm_nand.c

-- 
2.11.0

[PATCH v1 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

This patch adds the new IP of NAND Flash Controller support on Intel's
Lightning Mountain(LGM) SoC.

DMA is used for burst data transfer operation, also DMA HW supports
aligned 32bit memory address and aligned data access by default.
DMA burst of 8 supported,Data register used to support the read/write
operation from/to device.

The NAND controller Subsystem consisting of LGM + ECC-NAND controller supports:
NAND Flash Features :
-16/8-bit data bus
  Page + OOB Bytes
- 512  + (2 - 13) bytes per page page
- 2048 + (7 - 210) bytes per page
- 4096 + (13 - 420) bytes per page
- 8192 + (26 - 840) bytes per page

- Support 32/64/128/256/512/1024/2048/4096/8192/16384/32768 Mbytes flash device
- ECC calculation/generation and verification on-the-fly

Ramuthevar Vadivel Murugan (2):
  dt-bindings: mtd: Add YAML for Nand Flash Controller support
  mtd: rawnand: Add NAND controller support on Intel LGM SoC

 .../devicetree/bindings/mtd/intel,lgm-nand.yaml    |  61 ++
 drivers/mtd/nand/raw/Kconfig                       |   7 +
 drivers/mtd/nand/raw/Makefile                      |   1 +
 drivers/mtd/nand/raw/intel_lgm_nand.c              | 678 +++++++++++++++++++++
 4 files changed, 747 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
 create mode 100644 drivers/mtd/nand/raw/intel_lgm_nand.c

-- 
2.11.0


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

[PATCH v1 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>

Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
---
 .../devicetree/bindings/mtd/intel,lgm-nand.yaml    | 61 ++++++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml

diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index 000000000000..361e5051c602
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+  - $ref: "nand-controller.yaml"
+
+maintainers:
+  - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
+
+properties:
+  compatible:
+    const: intel,lgm-nand
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  dmas:
+    maxItems: 2
+
+  dma-names:
+    enum:
+      - rx
+      - tx
+
+  pinctrl-names: true
+
+patternProperties:
+  "^pinctrl-[0-9]+$": true
+
+  "^nand@[a-f0-9]+$":
+    type: object
+    properties:
+      reg:
+        minimum: 0
+        maximum: 7
+
+      nand-ecc-mode: true
+
+      nand-ecc-algo:
+        const: hw
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - dmas
+
+additionalProperties: false
+
+...
-- 
2.11.0

[PATCH v1 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support

[Ramuthevar, Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>

Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
---
 .../devicetree/bindings/mtd/intel,lgm-nand.yaml    | 61 ++++++++++++++++++++++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml

diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
new file mode 100644
index 000000000000..361e5051c602
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM SoC NAND Controller Device Tree Bindings
+
+allOf:
+  - $ref: "nand-controller.yaml"
+
+maintainers:
+  - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
+
+properties:
+  compatible:
+    const: intel,lgm-nand
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+
+  dmas:
+    maxItems: 2
+
+  dma-names:
+    enum:
+      - rx
+      - tx
+
+  pinctrl-names: true
+
+patternProperties:
+  "^pinctrl-[0-9]+$": true
+
+  "^nand@[a-f0-9]+$":
+    type: object
+    properties:
+      reg:
+        minimum: 0
+        maximum: 7
+
+      nand-ecc-mode: true
+
+      nand-ecc-algo:
+        const: hw
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - dmas
+
+additionalProperties: false
+
+...
-- 
2.11.0


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

Re: [PATCH v1 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support

[Boris Brezillon]

On Tue, 14 Apr 2020 10:24:32 +0800
"Ramuthevar,Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> 
> Add YAML file for dt-bindings to support NAND Flash Controller
> on Intel's Lightning Mountain SoC.
> 
> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> ---
>  .../devicetree/bindings/mtd/intel,lgm-nand.yaml    | 61 ++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> new file mode 100644
> index 000000000000..361e5051c602
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> @@ -0,0 +1,61 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel LGM SoC NAND Controller Device Tree Bindings
> +
> +allOf:
> +  - $ref: "nand-controller.yaml"
> +
> +maintainers:
> +  - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> +
> +properties:
> +  compatible:
> +    const: intel,lgm-nand

intel,lgm-nand-controller

> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  dmas:
> +    maxItems: 2
> +
> +  dma-names:
> +    enum:
> +      - rx
> +      - tx
> +
> +  pinctrl-names: true
> +
> +patternProperties:
> +  "^pinctrl-[0-9]+$": true
> +
> +  "^nand@[a-f0-9]+$":
> +    type: object
> +    properties:
> +      reg:
> +        minimum: 0
> +        maximum: 7
> +
> +      nand-ecc-mode: true
> +
> +      nand-ecc-algo:
> +        const: hw
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - dmas
> +
> +additionalProperties: false
> +
> +...

Re: [PATCH v1 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support

[Boris Brezillon]

On Tue, 14 Apr 2020 10:24:32 +0800
"Ramuthevar,Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> 
> Add YAML file for dt-bindings to support NAND Flash Controller
> on Intel's Lightning Mountain SoC.
> 
> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> ---
>  .../devicetree/bindings/mtd/intel,lgm-nand.yaml    | 61 ++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> new file mode 100644
> index 000000000000..361e5051c602
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> @@ -0,0 +1,61 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel LGM SoC NAND Controller Device Tree Bindings
> +
> +allOf:
> +  - $ref: "nand-controller.yaml"
> +
> +maintainers:
> +  - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> +
> +properties:
> +  compatible:
> +    const: intel,lgm-nand

intel,lgm-nand-controller

> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +
> +  dmas:
> +    maxItems: 2
> +
> +  dma-names:
> +    enum:
> +      - rx
> +      - tx
> +
> +  pinctrl-names: true
> +
> +patternProperties:
> +  "^pinctrl-[0-9]+$": true
> +
> +  "^nand@[a-f0-9]+$":
> +    type: object
> +    properties:
> +      reg:
> +        minimum: 0
> +        maximum: 7
> +
> +      nand-ecc-mode: true
> +
> +      nand-ecc-algo:
> +        const: hw
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - dmas
> +
> +additionalProperties: false
> +
> +...


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

Re: [PATCH v1 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

     Thank you so much for the review comments and your time...

On 1 4/4/2020 3:04 pm, Boris Brezillon wrote:
> On Tue, 14 Apr 2020 10:24:32 +0800
> "Ramuthevar,Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>
>> Add YAML file for dt-bindings to support NAND Flash Controller
>> on Intel's Lightning Mountain SoC.
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>> ---
>>   .../devicetree/bindings/mtd/intel,lgm-nand.yaml    | 61 ++++++++++++++++++++++
>>   1 file changed, 61 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>> new file mode 100644
>> index 000000000000..361e5051c602
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>> @@ -0,0 +1,61 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Intel LGM SoC NAND Controller Device Tree Bindings
>> +
>> +allOf:
>> +  - $ref: "nand-controller.yaml"
>> +
>> +maintainers:
>> +  - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>> +
>> +properties:
>> +  compatible:
>> +    const: intel,lgm-nand
> intel,lgm-nand-controller

Noted, will update in the next patch.

Regards
Vadivel
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  dmas:
>> +    maxItems: 2
>> +
>> +  dma-names:
>> +    enum:
>> +      - rx
>> +      - tx
>> +
>> +  pinctrl-names: true
>> +
>> +patternProperties:
>> +  "^pinctrl-[0-9]+$": true
>> +
>> +  "^nand@[a-f0-9]+$":
>> +    type: object
>> +    properties:
>> +      reg:
>> +        minimum: 0
>> +        maximum: 7
>> +
>> +      nand-ecc-mode: true
>> +
>> +      nand-ecc-algo:
>> +        const: hw
>> +
>> +    additionalProperties: false
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +  - dmas
>> +
>> +additionalProperties: false
>> +
>> +...

Re: [PATCH v1 1/2] dt-bindings: mtd: Add YAML for Nand Flash Controller support

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

     Thank you so much for the review comments and your time...

On 1 4/4/2020 3:04 pm, Boris Brezillon wrote:
> On Tue, 14 Apr 2020 10:24:32 +0800
> "Ramuthevar,Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>
>> Add YAML file for dt-bindings to support NAND Flash Controller
>> on Intel's Lightning Mountain SoC.
>>
>> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>> ---
>>   .../devicetree/bindings/mtd/intel,lgm-nand.yaml    | 61 ++++++++++++++++++++++
>>   1 file changed, 61 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>> new file mode 100644
>> index 000000000000..361e5051c602
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>> @@ -0,0 +1,61 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Intel LGM SoC NAND Controller Device Tree Bindings
>> +
>> +allOf:
>> +  - $ref: "nand-controller.yaml"
>> +
>> +maintainers:
>> +  - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>> +
>> +properties:
>> +  compatible:
>> +    const: intel,lgm-nand
> intel,lgm-nand-controller

Noted, will update in the next patch.

Regards
Vadivel
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +
>> +  dmas:
>> +    maxItems: 2
>> +
>> +  dma-names:
>> +    enum:
>> +      - rx
>> +      - tx
>> +
>> +  pinctrl-names: true
>> +
>> +patternProperties:
>> +  "^pinctrl-[0-9]+$": true
>> +
>> +  "^nand@[a-f0-9]+$":
>> +    type: object
>> +    properties:
>> +      reg:
>> +        minimum: 0
>> +        maximum: 7
>> +
>> +      nand-ecc-mode: true
>> +
>> +      nand-ecc-algo:
>> +        const: hw
>> +
>> +    additionalProperties: false
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - clocks
>> +  - clock-names
>> +  - dmas
>> +
>> +additionalProperties: false
>> +
>> +...

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

[PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>

This patch adds the new IP of Nand Flash Controller(NFC) support
on Intel's Lightning Mountain(LGM) SoC.

DMA is used for burst data transfer operation, also DMA HW supports
aligned 32bit memory address and aligned data access by default.
DMA burst of 8 supported. Data register used to support the read/write
operation from/to device.

Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
---
 drivers/mtd/nand/raw/Kconfig          |   7 +
 drivers/mtd/nand/raw/Makefile         |   1 +
 drivers/mtd/nand/raw/intel_lgm_nand.c | 678 ++++++++++++++++++++++++++++++++++
 3 files changed, 686 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/intel_lgm_nand.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index a80a46bb5b8b..9efc4bbaf4a3 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -457,6 +457,13 @@ config MTD_NAND_CADENCE
 	  Enable the driver for NAND flash on platforms using a Cadence NAND
 	  controller.
 
+config MTD_NAND_INTEL_LGM
+	tristate "Support for NAND controller on Intel LGM SoC"
+	depends on X86
+	help
+	  Enables support for NAND Flash chips on Intel's LGM SoC.
+          NAND flash interfaced through the External Bus Unit.
+
 comment "Misc"
 
 config MTD_SM_COMMON
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 2d136b158fb7..49a301ae0c9d 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA)		+= tegra_nand.o
 obj-$(CONFIG_MTD_NAND_STM32_FMC2)	+= stm32_fmc2_nand.o
 obj-$(CONFIG_MTD_NAND_MESON)		+= meson_nand.o
 obj-$(CONFIG_MTD_NAND_CADENCE)		+= cadence-nand-controller.o
+obj-$(CONFIG_MTD_NAND_INTEL_LGM)	+= intel_lgm_nand.o
 
 nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o
 nand-objs += nand_onfi.o
diff --git a/drivers/mtd/nand/raw/intel_lgm_nand.c b/drivers/mtd/nand/raw/intel_lgm_nand.c
new file mode 100644
index 000000000000..9c307c14c3eb
--- /dev/null
+++ b/drivers/mtd/nand/raw/intel_lgm_nand.c
@@ -0,0 +1,678 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2019 Intel Corporation. */
+
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-direction.h>
+#include <linux/dma-mapping.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/rawnand.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define LGM_CLC			0x000
+#define LGM_CLC_RST		0x00000000u
+
+#define LGM_NAND_ECC_OFFSET	0x008
+
+#define LGM_ADDR_SEL(n)		(0x20 + (n) * 4)
+#define LGM_ADDR_MASK		(5 << 4)
+#define LGM_ADDR_SEL_REGEN	0x1
+
+#define LGM_BUSCON(n)		(0x60 + (n) * 4)
+#define LGM_BUSCON_CMULT_V4	0x1
+#define LGM_BUSCON_RECOVC(n)	((n) << 2)
+#define LGM_BUSCON_HOLDC(n)	((n) << 4)
+#define LGM_BUSCON_WAITRDC(n)	((n) << 6)
+#define LGM_BUSCON_WAITWRC(n)	((n) << 8)
+#define LGM_BUSCON_BCGEN_CS	0x0
+#define LGM_BUSCON_SETUP_EN	BIT(22)
+#define LGM_BUSCON_ALEC		0xC000
+
+#define NAND_CON		0x0B0
+#define NAND_CON_NANDM_EN	BIT(0)
+#define NAND_CON_NANDM_DIS	0x0
+#define NAND_CON_CSMUX_E_EN	BIT(1)
+#define NAND_CON_ALE_P_LOW	BIT(2)
+#define NAND_CON_CLE_P_LOW	BIT(3)
+#define NAND_CON_CS_P_LOW	BIT(4)
+#define NAND_CON_SE_P_LOW	BIT(5)
+#define NAND_CON_WP_P_LOW	BIT(6)
+#define NAND_CON_PRE_P_LOW	BIT(7)
+#define NAND_CON_IN_CS_S(n)	((n) << 8)
+#define NAND_CON_OUT_CS_S(n)	((n) << 10)
+#define NAND_CON_LAT_EN_CS_P	((0x3D) << 18)
+
+#define NAND_WAIT		0x0B4
+#define NAND_WAIT_RDBY		BIT(0)
+#define NAND_WAIT_WR_C		BIT(3)
+
+#define NAND_CTL1		0x110
+#define NAND_CTL1_ADDR_3_SHIFT	24
+
+#define NAND_CTL2		0x114
+#define NAND_CTL2_ADDR_5_SHIFT	8
+#define NAND_CTL2_CYC_N_V5	(0x2 << 16)
+
+#define NAND_INT_MSK_CTL	0x124
+#define NAND_INT_MSK_CTL_WR_C	BIT(4)
+
+#define NAND_INT_STA		0x128
+#define NAND_INT_STA_WR_C	BIT(4)
+
+#define NAND_CTL		0x130
+#define NAND_CTL_MODE_ECC	0x1
+#define NAND_CTL_GO		BIT(2)
+#define NAND_CTL_CE_SEL_CS(n)	BIT(3 + (n))
+#define NAND_CTL_RW_READ	0x0
+#define NAND_CTL_RW_WRITE	BIT(10)
+#define NAND_CTL_ECC_OFF_V8TH	BIT(11)
+#define NAND_CTL_CKFF_EN	0x0
+#define NAND_CTL_MSG_EN		BIT(17)
+
+#define NAND_PARA0		0x13c
+#define NAND_PARA0_PAGE_V8192	0x3
+#define NAND_PARA0_PIB_V256	(0x3 << 4)
+#define NAND_PARA0_BYP_EN_NP	0x0
+#define NAND_PARA0_BYP_DEC_NP	0x0
+#define NAND_PARA0_TYPE_ONFI	BIT(18)
+#define NAND_PARA0_ADEP_EN	BIT(21)
+
+#define NAND_CMSG_0		0x150
+#define NAND_CMSG_1		0x154
+
+#define NAND_WRITE_CMD		(NAND_CON_CS_P_LOW | NAND_CON_CLE_P_LOW)
+#define NAND_WRITE_ADDR		(NAND_CON_CS_P_LOW | NAND_CON_ALE_P_LOW)
+#define NAND_WRITE_DATA		NAND_CON_CS_P_LOW
+#define NAND_READ_DATA		NAND_CON_CS_P_LOW
+
+#define NAND_CHIP_NO_SELECTION	-1
+#define NAND_CHIP_SELECTION	0x0
+
+struct lgm_nand_host {
+	struct nand_chip	chip;
+	void __iomem		*lgm_va;
+	void __iomem		*hsnand_va;
+	void __iomem		*nandaddr_va;
+	struct clk		*clk;
+	unsigned long		clk_rate;
+	u32			cs;
+	u32			nd_para0;
+	struct device		*dev;
+	struct dma_chan		*dma_tx;
+	struct dma_chan		*dma_rx;
+	struct completion	dma_access_complete;
+	const char *cs_name;
+};
+
+static u8 lgm_nand_readb(struct nand_chip *chip, int op)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *nand_wait = lgm_host->lgm_va + NAND_WAIT;
+	u32 stat;
+	int ret;
+	u8 val;
+
+	val = readb(lgm_host->nandaddr_va + op);
+
+	ret = readl_poll_timeout(nand_wait, stat, stat & NAND_WAIT_WR_C,
+				 20, 1000);
+	if (ret)
+		dev_warn(lgm_host->dev,
+			 "lgm nand write timeout. nand_wait(0x%p)=0x%x\n",
+			 nand_wait, readl(nand_wait));
+
+	return val;
+}
+
+static void lgm_nand_writeb(struct nand_chip *chip, int op, u8 value)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *nand_wait = lgm_host->lgm_va + NAND_WAIT;
+	u32 stat;
+	int ret;
+
+	writeb(value, lgm_host->nandaddr_va + op);
+
+	ret = readl_poll_timeout(nand_wait, stat, stat & NAND_WAIT_WR_C,
+				 20, 1000);
+	if (ret)
+		dev_warn(lgm_host->dev,
+			 "lgm nand write timeout. nand_wait(0x%p)=0x%x\n",
+			 nand_wait, readl(nand_wait));
+}
+
+static unsigned char lgm_read_byte(struct nand_chip *chip)
+{
+	return lgm_nand_readb(chip, NAND_READ_DATA);
+}
+
+static void lgm_read_buf(struct nand_chip *chip, u_char *buf, int len)
+{
+	int i;
+
+	for (i = 0; i < len; i++)
+		buf[i] = lgm_nand_readb(chip, NAND_WRITE_DATA);
+}
+
+static void lgm_write_buf(struct nand_chip *chip, const u_char *buf, int len)
+{
+	int i;
+
+	for (i = 0; i < len; i++)
+		lgm_nand_writeb(chip, NAND_WRITE_DATA, buf[i]);
+}
+
+static void lgm_select_chip(struct nand_chip *chip, int select)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *nand_con = lgm_host->lgm_va + NAND_CON;
+	u32 cs = lgm_host->cs;
+	int val;
+
+	switch (select) {
+	case NAND_CHIP_NO_SELECTION:
+		val = readl(nand_con);
+		writel(val & ~NAND_CON_NANDM_EN, nand_con);
+		break;
+	case NAND_CHIP_SELECTION:
+		writel(NAND_CON_NANDM_EN | NAND_CON_CSMUX_E_EN |
+		       NAND_CON_CS_P_LOW | NAND_CON_SE_P_LOW |
+		       NAND_CON_WP_P_LOW | NAND_CON_PRE_P_LOW |
+		       NAND_CON_IN_CS_S(cs) | NAND_CON_OUT_CS_S(cs) |
+		       NAND_CON_LAT_EN_CS_P, nand_con);
+		break;
+	default:
+		break;
+	}
+}
+
+static int lgm_dev_ready(struct nand_chip *chip)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+
+	return readl(lgm_host->lgm_va + NAND_WAIT) & NAND_WAIT_RDBY;
+}
+
+static void lgm_cmd_ctrl(struct nand_chip *chip, int cmd, unsigned int ctrl)
+{
+	if (cmd == NAND_CMD_NONE)
+		return;
+
+	if (ctrl & NAND_CLE)
+		lgm_nand_writeb(chip, NAND_WRITE_CMD, cmd);
+	else if (ctrl & NAND_ALE)
+		lgm_nand_writeb(chip, NAND_WRITE_ADDR, cmd);
+}
+
+static int lgm_nand_ooblayout_ecc(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = LGM_NAND_ECC_OFFSET;
+	oobregion->length = chip->ecc.total;
+
+	return 0;
+}
+
+static int lgm_nand_ooblayout_free(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = chip->ecc.total + LGM_NAND_ECC_OFFSET;
+	oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops lgm_nand_ooblayout_ops = {
+	.ecc = lgm_nand_ooblayout_ecc,
+	.free = lgm_nand_ooblayout_free,
+};
+
+static void lgm_dma_rx_callback(void *cookie)
+{
+	struct lgm_nand_host *lgm_host = cookie;
+
+	dmaengine_terminate_async(lgm_host->dma_rx);
+
+	complete(&lgm_host->dma_access_complete);
+}
+
+static void lgm_dma_tx_callback(void *cookie)
+{
+	struct lgm_nand_host *lgm_host = cookie;
+
+	dmaengine_terminate_async(lgm_host->dma_tx);
+
+	complete(&lgm_host->dma_access_complete);
+}
+
+static int lgm_dma_start(struct lgm_nand_host *lgm_host, u32 dir,
+			 const u8 *buf, u32 len)
+{
+	struct dma_async_tx_descriptor *tx;
+	struct completion *dma_completion;
+	dma_async_tx_callback callback;
+	struct dma_chan *chan;
+	dma_cookie_t cookie;
+	unsigned long flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+	dma_addr_t buf_dma;
+	int ret;
+	u32 timeout;
+
+	if (dir == DMA_DEV_TO_MEM) {
+		chan = lgm_host->dma_rx;
+		dma_completion = &lgm_host->dma_access_complete;
+		callback = lgm_dma_rx_callback;
+	} else {
+		chan = lgm_host->dma_tx;
+		dma_completion = &lgm_host->dma_access_complete;
+		callback = lgm_dma_tx_callback;
+	}
+
+	buf_dma = dma_map_single(chan->device->dev, (void *)buf, len, dir);
+	if (dma_mapping_error(chan->device->dev, buf_dma)) {
+		dev_err(lgm_host->dev, "Failed to map DMA buffer\n");
+		ret = -EIO;
+		goto err_unmap;
+	}
+
+	tx = dmaengine_prep_slave_single(chan, buf_dma, len, dir, flags);
+	if (!tx)
+		return -ENXIO;
+
+	tx->callback = callback;
+	tx->callback_param = lgm_host;
+	cookie = tx->tx_submit(tx);
+
+	ret = dma_submit_error(cookie);
+	if (ret) {
+		dev_err(lgm_host->dev, "dma_submit_error %d\n", cookie);
+		ret = -EIO;
+		goto err_unmap;
+	}
+
+	init_completion(dma_completion);
+	dma_async_issue_pending(chan);
+
+	/* Wait DMA to finish the data transfer.*/
+	timeout =
+	wait_for_completion_timeout(dma_completion, msecs_to_jiffies(1000));
+	if (!timeout) {
+		dev_err(lgm_host->dev, "I/O Error in DMA RX (status %d)\n",
+			dmaengine_tx_status(chan, cookie, NULL));
+		dmaengine_terminate_sync(chan);
+		ret = -ETIMEDOUT;
+		goto err_unmap;
+	}
+
+	return 0;
+
+err_unmap:
+	dma_unmap_single(lgm_host->dev, buf_dma, len, dir);
+
+	return ret;
+}
+
+static void lgm_nand_trigger(struct lgm_nand_host *lgm_host, int page, u32 cmd)
+{
+	unsigned int val;
+
+	val = cmd | (page & 0xFF) << NAND_CTL1_ADDR_3_SHIFT;
+	writel(val, lgm_host->hsnand_va + NAND_CTL1);
+	val = (page & 0xFFFF00) >> 8 | NAND_CTL2_CYC_N_V5;
+	writel(val, lgm_host->hsnand_va + NAND_CTL2);
+
+	writel(lgm_host->nd_para0, lgm_host->hsnand_va + NAND_PARA0);
+
+	/* clear first, will update later */
+	writel(0xFFFFFFFF, lgm_host->hsnand_va + NAND_CMSG_0);
+	writel(0xFFFFFFFF, lgm_host->hsnand_va + NAND_CMSG_1);
+
+	writel(NAND_INT_MSK_CTL_WR_C, lgm_host->hsnand_va + NAND_INT_MSK_CTL);
+
+	val = cmd == NAND_CMD_READ0 ? NAND_CTL_RW_READ : NAND_CTL_RW_WRITE;
+
+	writel(NAND_CTL_MSG_EN | NAND_CTL_CKFF_EN | NAND_CTL_ECC_OFF_V8TH |
+	       NAND_CTL_CE_SEL_CS(lgm_host->cs) | NAND_CTL_MODE_ECC |
+	       NAND_CTL_GO | val, lgm_host->hsnand_va + NAND_CTL);
+}
+
+static int lgm_nand_read_page_hwecc(struct nand_chip *chip, u8 *buf,
+				    int oob_required, int page)
+{
+	struct mtd_info *mtd = nand_to_mtd(chip);
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	int ret, x;
+
+	lgm_nand_trigger(lgm_host, page, NAND_CMD_READ0);
+
+	ret = lgm_dma_start(lgm_host, DMA_DEV_TO_MEM, buf, mtd->writesize);
+	if (ret)
+		return ret;
+
+	if (oob_required)
+		chip->ecc.read_oob(chip, page);
+
+	x = readl(lgm_host->hsnand_va + NAND_CTL);
+	x &= ~NAND_CTL_GO;
+	writel(x, lgm_host->hsnand_va + NAND_CTL);
+
+	return 0;
+}
+
+static int lgm_nand_write_page_hwecc(struct nand_chip *chip, const u8 *buf,
+				     int oob_required, int page)
+{
+	struct mtd_info *mtd = nand_to_mtd(chip);
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *int_sta = lgm_host->hsnand_va + NAND_INT_STA;
+	int ret, val, x;
+	__be32 reg;
+
+	lgm_nand_trigger(lgm_host, page, NAND_CMD_SEQIN);
+
+	ret = lgm_dma_start(lgm_host, DMA_MEM_TO_DEV, buf, mtd->writesize);
+	if (ret)
+		return ret;
+
+	if (oob_required) {
+		const u8 *pdata;
+
+		pdata = chip->oob_poi;
+		reg = cpu_to_be32(*pdata++);
+		writel(reg, lgm_host->hsnand_va + NAND_CMSG_0);
+
+		reg = cpu_to_be32(*pdata);
+		writel(reg, lgm_host->hsnand_va + NAND_CMSG_1);
+	}
+
+	ret = readl_poll_timeout_atomic(int_sta, val,
+					!(val & NAND_INT_STA_WR_C), 10, 1000);
+	if (ret)
+		return -EIO;
+
+	x = readl(lgm_host->hsnand_va + NAND_CTL);
+	x &= ~NAND_CTL_GO;
+	writel(x, lgm_host->hsnand_va + NAND_CTL);
+
+	return 0;
+}
+
+static const u8 ecc_strength[] = { 1, 1, 4, 8, 24, 32, 40, 60, };
+
+static int lgm_nand_attach_chip(struct nand_chip *chip)
+{
+	struct mtd_info *mtd = nand_to_mtd(chip);
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	u32 eccsize, eccsteps, eccbytes, ecctotal, pagesize, pg_per_blk;
+	u32 eccstrength = chip->ecc.strength;
+	u32 writesize = mtd->writesize;
+	u32 blocksize = mtd->erasesize;
+	int start, val, i;
+
+	if (chip->ecc.mode != NAND_ECC_HW)
+		return 0;
+
+	/* Check whether eccsize is 0x0 or wrong. assign eccsize = 512 if YES */
+	if (!chip->ecc.size)
+		chip->ecc.size = 512;
+	eccsize = chip->ecc.size;
+
+	switch (eccsize) {
+	case 512:
+		start = 1;
+		if (!eccstrength)
+			eccstrength = 4;
+		break;
+	case 1024:
+		start = 4;
+		if (!eccstrength)
+			eccstrength = 32;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	i = round_up(start + 1, 4);
+	for (val = start; val < i; val++) {
+		if (eccstrength == ecc_strength[val])
+			break;
+	}
+	if (val == i)
+		return -EINVAL;
+
+	if (eccstrength == 8)
+		eccbytes = 14;
+	else
+		eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
+
+	eccsteps = writesize / eccsize;
+	ecctotal = eccsteps * eccbytes;
+	if ((ecctotal + 8) > mtd->oobsize)
+		return -ERANGE;
+
+	chip->ecc.total = ecctotal;
+	pagesize = fls(writesize >> 11);
+	if (pagesize > NAND_PARA0_PAGE_V8192)
+		return -ERANGE;
+
+	pg_per_blk = fls((blocksize / writesize) >> 6) << 4;
+	if (pg_per_blk > NAND_PARA0_PIB_V256)
+		return -ERANGE;
+
+	lgm_host->nd_para0 = pagesize | pg_per_blk | NAND_PARA0_BYP_EN_NP |
+			     NAND_PARA0_BYP_DEC_NP | NAND_PARA0_ADEP_EN |
+			     NAND_PARA0_TYPE_ONFI | (val << 29);
+
+	mtd_set_ooblayout(mtd, &lgm_nand_ooblayout_ops);
+	chip->ecc.read_page = lgm_nand_read_page_hwecc;
+	chip->ecc.write_page = lgm_nand_write_page_hwecc;
+
+	return 0;
+}
+
+static const struct nand_controller_ops lgm_nand_controller_ops = {
+	.attach_chip = lgm_nand_attach_chip,
+};
+
+static void lgm_dma_exit(struct lgm_nand_host *lgm_host)
+{
+	if (lgm_host->dma_rx) {
+		dma_release_channel(lgm_host->dma_rx);
+		lgm_host->dma_rx = NULL;
+	}
+
+	if (lgm_host->dma_tx) {
+		dma_release_channel(lgm_host->dma_tx);
+		lgm_host->dma_tx = NULL;
+	}
+}
+
+static int lgm_dma_init(struct device *dev, struct lgm_nand_host *lgm_host)
+{
+	int ret;
+
+	/* Prepare for TX DMA: */
+	lgm_host->dma_tx = dma_request_chan(dev, "tx");
+	if (IS_ERR(lgm_host->dma_tx)) {
+		ret = PTR_ERR(lgm_host->dma_tx);
+		dev_err(dev, "can't get the TX DMA channel, error %d!\n", ret);
+		goto err;
+	}
+
+	/* Prepare for RX: */
+	lgm_host->dma_rx = dma_request_chan(dev, "rx");
+	if (IS_ERR(lgm_host->dma_rx)) {
+		ret = PTR_ERR(lgm_host->dma_rx);
+		dev_err(dev, "can't get the RX DMA channel, error %d\n", ret);
+		goto err;
+	}
+
+	return 0;
+err:
+	return ret;
+}
+
+static int lgm_nand_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct lgm_nand_host *lgm_host;
+	phys_addr_t nandaddr_pa;
+	struct mtd_info *mtd;
+	struct resource *res;
+	int ret;
+	u32 cs;
+
+	lgm_host = devm_kzalloc(dev, sizeof(*lgm_host), GFP_KERNEL);
+	if (!lgm_host)
+		return -ENOMEM;
+
+	lgm_host->lgm_va = devm_platform_ioremap_resource_byname(pdev, "lgmnand");
+	if (IS_ERR(lgm_host->lgm_va))
+		return PTR_ERR(lgm_host->lgm_va);
+
+	lgm_host->hsnand_va = devm_platform_ioremap_resource_byname(pdev, "hsnand");
+	if (IS_ERR(lgm_host->hsnand_va))
+		return PTR_ERR(lgm_host->hsnand_va);
+
+	ret = device_property_read_u32(dev, "nand,cs", &cs);
+	if (ret) {
+		dev_err(dev, "failed to get chip select: %d\n", ret);
+		return ret;
+	}
+
+	lgm_host->cs = cs;
+
+	lgm_host->cs_name = devm_kasprintf(dev, GFP_KERNEL, "nand_cs%d", cs);
+	if (IS_ERR(lgm_host->cs_name)) {
+		ret = PTR_ERR(lgm_host->cs_name);
+		dev_err(dev, "failed to get chip select name: %d\n", ret);
+		return ret;
+	}
+
+	res = devm_platform_ioremap_resource_byname(pdev, lgm_host->cs_name);
+	lgm_host->nandaddr_va = res;
+	nandaddr_pa = res->start;
+	if (IS_ERR(lgm_host->nandaddr_va))
+		return PTR_ERR(lgm_host->nandaddr_va);
+
+	lgm_host->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(lgm_host->clk)) {
+		ret = PTR_ERR(lgm_host->clk);
+		dev_err(dev, "failed to get clock: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(lgm_host->clk);
+	if (ret) {
+		dev_err(dev, "failed to enable clock: %d\n", ret);
+		return ret;
+	}
+	lgm_host->clk_rate = clk_get_rate(lgm_host->clk);
+
+	ret = lgm_dma_init(dev, lgm_host);
+	if (ret)
+		goto disable_clk;
+
+	writel(lower_32_bits(nandaddr_pa) | LGM_ADDR_SEL_REGEN | LGM_ADDR_MASK,
+	       lgm_host->lgm_va + LGM_ADDR_SEL(cs));
+
+	writel(LGM_BUSCON_CMULT_V4 | LGM_BUSCON_RECOVC(1) |
+	       LGM_BUSCON_HOLDC(1) | LGM_BUSCON_WAITRDC(2) |
+	       LGM_BUSCON_WAITWRC(2) | LGM_BUSCON_BCGEN_CS | LGM_BUSCON_ALEC |
+	       LGM_BUSCON_SETUP_EN, lgm_host->lgm_va + LGM_BUSCON(cs));
+
+	/*
+	 * NAND physical address selection is based on the chip select
+	 * and written to ADDR_SEL register to get Memory Region Base address.
+	 * FPI Bus addresses are compared to this base address in conjunction
+	 * with the mask control. Driver need to program this field!
+	 * Address: 0x17400 if chip select is CS_0
+	 * Address: 0x17C00 if chip select is CS_1
+	 * Refer the Intel LGM SoC datasheet.
+	 */
+	writel(0x17400051, lgm_host->lgm_va + LGM_ADDR_SEL(0));
+	writel(0x17C00051, lgm_host->lgm_va + LGM_ADDR_SEL(cs));
+	nand_set_flash_node(&lgm_host->chip, dev->of_node);
+	mtd = nand_to_mtd(&lgm_host->chip);
+	mtd->dev.parent = dev;
+	lgm_host->dev = dev;
+
+	platform_set_drvdata(pdev, lgm_host);
+	nand_set_controller_data(&lgm_host->chip, lgm_host);
+
+	lgm_host->chip.legacy.read_byte = lgm_read_byte;
+	lgm_host->chip.legacy.read_buf = lgm_read_buf;
+	lgm_host->chip.legacy.write_buf = lgm_write_buf;
+	lgm_host->chip.legacy.select_chip = lgm_select_chip;
+	lgm_host->chip.legacy.dev_ready = lgm_dev_ready;
+	lgm_host->chip.legacy.cmd_ctrl = lgm_cmd_ctrl;
+	lgm_host->chip.legacy.chip_delay = 30;
+	lgm_host->chip.legacy.dummy_controller.ops = &lgm_nand_controller_ops;
+
+	/* Scan to find existence of the device */
+	ret = nand_scan(&lgm_host->chip, 1);
+	if (ret)
+		goto exit_dma;
+
+	ret = mtd_device_register(mtd, NULL, 0);
+	if (ret)
+		goto clean_nand;
+
+	return 0;
+
+clean_nand:
+	nand_cleanup(&lgm_host->chip);
+exit_dma:
+	lgm_dma_exit(lgm_host);
+disable_clk:
+	clk_disable_unprepare(lgm_host->clk);
+
+	return ret;
+}
+
+static int lgm_nand_remove(struct platform_device *pdev)
+{
+	struct lgm_nand_host *lgm_host = platform_get_drvdata(pdev);
+
+	nand_release(&lgm_host->chip);
+	clk_disable_unprepare(lgm_host->clk);
+	lgm_dma_exit(lgm_host);
+
+	return 0;
+}
+
+static const struct of_device_id lgm_nand_match[] = {
+	{ .compatible = "intel,lgm-nand", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, lgm_nand_match);
+
+static struct platform_driver lgm_nand_driver = {
+	.probe = lgm_nand_probe,
+	.remove = lgm_nand_remove,
+	.driver = {
+		.name = "intel-lgm-nand",
+		.of_match_table = lgm_nand_match,
+	},
+
+};
+module_platform_driver(lgm_nand_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Vadivel Murugan R <vadivel.muruganx.ramuthevar@intel.com>");
+MODULE_DESCRIPTION("Intel's LGM External Bus NAND Controller driver");
-- 
2.11.0

[PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>

This patch adds the new IP of Nand Flash Controller(NFC) support
on Intel's Lightning Mountain(LGM) SoC.

DMA is used for burst data transfer operation, also DMA HW supports
aligned 32bit memory address and aligned data access by default.
DMA burst of 8 supported. Data register used to support the read/write
operation from/to device.

Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
---
 drivers/mtd/nand/raw/Kconfig          |   7 +
 drivers/mtd/nand/raw/Makefile         |   1 +
 drivers/mtd/nand/raw/intel_lgm_nand.c | 678 ++++++++++++++++++++++++++++++++++
 3 files changed, 686 insertions(+)
 create mode 100644 drivers/mtd/nand/raw/intel_lgm_nand.c

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index a80a46bb5b8b..9efc4bbaf4a3 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -457,6 +457,13 @@ config MTD_NAND_CADENCE
 	  Enable the driver for NAND flash on platforms using a Cadence NAND
 	  controller.
 
+config MTD_NAND_INTEL_LGM
+	tristate "Support for NAND controller on Intel LGM SoC"
+	depends on X86
+	help
+	  Enables support for NAND Flash chips on Intel's LGM SoC.
+          NAND flash interfaced through the External Bus Unit.
+
 comment "Misc"
 
 config MTD_SM_COMMON
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 2d136b158fb7..49a301ae0c9d 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_NAND_TEGRA)		+= tegra_nand.o
 obj-$(CONFIG_MTD_NAND_STM32_FMC2)	+= stm32_fmc2_nand.o
 obj-$(CONFIG_MTD_NAND_MESON)		+= meson_nand.o
 obj-$(CONFIG_MTD_NAND_CADENCE)		+= cadence-nand-controller.o
+obj-$(CONFIG_MTD_NAND_INTEL_LGM)	+= intel_lgm_nand.o
 
 nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o
 nand-objs += nand_onfi.o
diff --git a/drivers/mtd/nand/raw/intel_lgm_nand.c b/drivers/mtd/nand/raw/intel_lgm_nand.c
new file mode 100644
index 000000000000..9c307c14c3eb
--- /dev/null
+++ b/drivers/mtd/nand/raw/intel_lgm_nand.c
@@ -0,0 +1,678 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2019 Intel Corporation. */
+
+#include <linux/clk.h>
+#include <linux/completion.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-direction.h>
+#include <linux/dma-mapping.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/rawnand.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define LGM_CLC			0x000
+#define LGM_CLC_RST		0x00000000u
+
+#define LGM_NAND_ECC_OFFSET	0x008
+
+#define LGM_ADDR_SEL(n)		(0x20 + (n) * 4)
+#define LGM_ADDR_MASK		(5 << 4)
+#define LGM_ADDR_SEL_REGEN	0x1
+
+#define LGM_BUSCON(n)		(0x60 + (n) * 4)
+#define LGM_BUSCON_CMULT_V4	0x1
+#define LGM_BUSCON_RECOVC(n)	((n) << 2)
+#define LGM_BUSCON_HOLDC(n)	((n) << 4)
+#define LGM_BUSCON_WAITRDC(n)	((n) << 6)
+#define LGM_BUSCON_WAITWRC(n)	((n) << 8)
+#define LGM_BUSCON_BCGEN_CS	0x0
+#define LGM_BUSCON_SETUP_EN	BIT(22)
+#define LGM_BUSCON_ALEC		0xC000
+
+#define NAND_CON		0x0B0
+#define NAND_CON_NANDM_EN	BIT(0)
+#define NAND_CON_NANDM_DIS	0x0
+#define NAND_CON_CSMUX_E_EN	BIT(1)
+#define NAND_CON_ALE_P_LOW	BIT(2)
+#define NAND_CON_CLE_P_LOW	BIT(3)
+#define NAND_CON_CS_P_LOW	BIT(4)
+#define NAND_CON_SE_P_LOW	BIT(5)
+#define NAND_CON_WP_P_LOW	BIT(6)
+#define NAND_CON_PRE_P_LOW	BIT(7)
+#define NAND_CON_IN_CS_S(n)	((n) << 8)
+#define NAND_CON_OUT_CS_S(n)	((n) << 10)
+#define NAND_CON_LAT_EN_CS_P	((0x3D) << 18)
+
+#define NAND_WAIT		0x0B4
+#define NAND_WAIT_RDBY		BIT(0)
+#define NAND_WAIT_WR_C		BIT(3)
+
+#define NAND_CTL1		0x110
+#define NAND_CTL1_ADDR_3_SHIFT	24
+
+#define NAND_CTL2		0x114
+#define NAND_CTL2_ADDR_5_SHIFT	8
+#define NAND_CTL2_CYC_N_V5	(0x2 << 16)
+
+#define NAND_INT_MSK_CTL	0x124
+#define NAND_INT_MSK_CTL_WR_C	BIT(4)
+
+#define NAND_INT_STA		0x128
+#define NAND_INT_STA_WR_C	BIT(4)
+
+#define NAND_CTL		0x130
+#define NAND_CTL_MODE_ECC	0x1
+#define NAND_CTL_GO		BIT(2)
+#define NAND_CTL_CE_SEL_CS(n)	BIT(3 + (n))
+#define NAND_CTL_RW_READ	0x0
+#define NAND_CTL_RW_WRITE	BIT(10)
+#define NAND_CTL_ECC_OFF_V8TH	BIT(11)
+#define NAND_CTL_CKFF_EN	0x0
+#define NAND_CTL_MSG_EN		BIT(17)
+
+#define NAND_PARA0		0x13c
+#define NAND_PARA0_PAGE_V8192	0x3
+#define NAND_PARA0_PIB_V256	(0x3 << 4)
+#define NAND_PARA0_BYP_EN_NP	0x0
+#define NAND_PARA0_BYP_DEC_NP	0x0
+#define NAND_PARA0_TYPE_ONFI	BIT(18)
+#define NAND_PARA0_ADEP_EN	BIT(21)
+
+#define NAND_CMSG_0		0x150
+#define NAND_CMSG_1		0x154
+
+#define NAND_WRITE_CMD		(NAND_CON_CS_P_LOW | NAND_CON_CLE_P_LOW)
+#define NAND_WRITE_ADDR		(NAND_CON_CS_P_LOW | NAND_CON_ALE_P_LOW)
+#define NAND_WRITE_DATA		NAND_CON_CS_P_LOW
+#define NAND_READ_DATA		NAND_CON_CS_P_LOW
+
+#define NAND_CHIP_NO_SELECTION	-1
+#define NAND_CHIP_SELECTION	0x0
+
+struct lgm_nand_host {
+	struct nand_chip	chip;
+	void __iomem		*lgm_va;
+	void __iomem		*hsnand_va;
+	void __iomem		*nandaddr_va;
+	struct clk		*clk;
+	unsigned long		clk_rate;
+	u32			cs;
+	u32			nd_para0;
+	struct device		*dev;
+	struct dma_chan		*dma_tx;
+	struct dma_chan		*dma_rx;
+	struct completion	dma_access_complete;
+	const char *cs_name;
+};
+
+static u8 lgm_nand_readb(struct nand_chip *chip, int op)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *nand_wait = lgm_host->lgm_va + NAND_WAIT;
+	u32 stat;
+	int ret;
+	u8 val;
+
+	val = readb(lgm_host->nandaddr_va + op);
+
+	ret = readl_poll_timeout(nand_wait, stat, stat & NAND_WAIT_WR_C,
+				 20, 1000);
+	if (ret)
+		dev_warn(lgm_host->dev,
+			 "lgm nand write timeout. nand_wait(0x%p)=0x%x\n",
+			 nand_wait, readl(nand_wait));
+
+	return val;
+}
+
+static void lgm_nand_writeb(struct nand_chip *chip, int op, u8 value)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *nand_wait = lgm_host->lgm_va + NAND_WAIT;
+	u32 stat;
+	int ret;
+
+	writeb(value, lgm_host->nandaddr_va + op);
+
+	ret = readl_poll_timeout(nand_wait, stat, stat & NAND_WAIT_WR_C,
+				 20, 1000);
+	if (ret)
+		dev_warn(lgm_host->dev,
+			 "lgm nand write timeout. nand_wait(0x%p)=0x%x\n",
+			 nand_wait, readl(nand_wait));
+}
+
+static unsigned char lgm_read_byte(struct nand_chip *chip)
+{
+	return lgm_nand_readb(chip, NAND_READ_DATA);
+}
+
+static void lgm_read_buf(struct nand_chip *chip, u_char *buf, int len)
+{
+	int i;
+
+	for (i = 0; i < len; i++)
+		buf[i] = lgm_nand_readb(chip, NAND_WRITE_DATA);
+}
+
+static void lgm_write_buf(struct nand_chip *chip, const u_char *buf, int len)
+{
+	int i;
+
+	for (i = 0; i < len; i++)
+		lgm_nand_writeb(chip, NAND_WRITE_DATA, buf[i]);
+}
+
+static void lgm_select_chip(struct nand_chip *chip, int select)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *nand_con = lgm_host->lgm_va + NAND_CON;
+	u32 cs = lgm_host->cs;
+	int val;
+
+	switch (select) {
+	case NAND_CHIP_NO_SELECTION:
+		val = readl(nand_con);
+		writel(val & ~NAND_CON_NANDM_EN, nand_con);
+		break;
+	case NAND_CHIP_SELECTION:
+		writel(NAND_CON_NANDM_EN | NAND_CON_CSMUX_E_EN |
+		       NAND_CON_CS_P_LOW | NAND_CON_SE_P_LOW |
+		       NAND_CON_WP_P_LOW | NAND_CON_PRE_P_LOW |
+		       NAND_CON_IN_CS_S(cs) | NAND_CON_OUT_CS_S(cs) |
+		       NAND_CON_LAT_EN_CS_P, nand_con);
+		break;
+	default:
+		break;
+	}
+}
+
+static int lgm_dev_ready(struct nand_chip *chip)
+{
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+
+	return readl(lgm_host->lgm_va + NAND_WAIT) & NAND_WAIT_RDBY;
+}
+
+static void lgm_cmd_ctrl(struct nand_chip *chip, int cmd, unsigned int ctrl)
+{
+	if (cmd == NAND_CMD_NONE)
+		return;
+
+	if (ctrl & NAND_CLE)
+		lgm_nand_writeb(chip, NAND_WRITE_CMD, cmd);
+	else if (ctrl & NAND_ALE)
+		lgm_nand_writeb(chip, NAND_WRITE_ADDR, cmd);
+}
+
+static int lgm_nand_ooblayout_ecc(struct mtd_info *mtd, int section,
+				  struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = LGM_NAND_ECC_OFFSET;
+	oobregion->length = chip->ecc.total;
+
+	return 0;
+}
+
+static int lgm_nand_ooblayout_free(struct mtd_info *mtd, int section,
+				   struct mtd_oob_region *oobregion)
+{
+	struct nand_chip *chip = mtd_to_nand(mtd);
+
+	if (section)
+		return -ERANGE;
+
+	oobregion->offset = chip->ecc.total + LGM_NAND_ECC_OFFSET;
+	oobregion->length = mtd->oobsize - oobregion->offset;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops lgm_nand_ooblayout_ops = {
+	.ecc = lgm_nand_ooblayout_ecc,
+	.free = lgm_nand_ooblayout_free,
+};
+
+static void lgm_dma_rx_callback(void *cookie)
+{
+	struct lgm_nand_host *lgm_host = cookie;
+
+	dmaengine_terminate_async(lgm_host->dma_rx);
+
+	complete(&lgm_host->dma_access_complete);
+}
+
+static void lgm_dma_tx_callback(void *cookie)
+{
+	struct lgm_nand_host *lgm_host = cookie;
+
+	dmaengine_terminate_async(lgm_host->dma_tx);
+
+	complete(&lgm_host->dma_access_complete);
+}
+
+static int lgm_dma_start(struct lgm_nand_host *lgm_host, u32 dir,
+			 const u8 *buf, u32 len)
+{
+	struct dma_async_tx_descriptor *tx;
+	struct completion *dma_completion;
+	dma_async_tx_callback callback;
+	struct dma_chan *chan;
+	dma_cookie_t cookie;
+	unsigned long flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+	dma_addr_t buf_dma;
+	int ret;
+	u32 timeout;
+
+	if (dir == DMA_DEV_TO_MEM) {
+		chan = lgm_host->dma_rx;
+		dma_completion = &lgm_host->dma_access_complete;
+		callback = lgm_dma_rx_callback;
+	} else {
+		chan = lgm_host->dma_tx;
+		dma_completion = &lgm_host->dma_access_complete;
+		callback = lgm_dma_tx_callback;
+	}
+
+	buf_dma = dma_map_single(chan->device->dev, (void *)buf, len, dir);
+	if (dma_mapping_error(chan->device->dev, buf_dma)) {
+		dev_err(lgm_host->dev, "Failed to map DMA buffer\n");
+		ret = -EIO;
+		goto err_unmap;
+	}
+
+	tx = dmaengine_prep_slave_single(chan, buf_dma, len, dir, flags);
+	if (!tx)
+		return -ENXIO;
+
+	tx->callback = callback;
+	tx->callback_param = lgm_host;
+	cookie = tx->tx_submit(tx);
+
+	ret = dma_submit_error(cookie);
+	if (ret) {
+		dev_err(lgm_host->dev, "dma_submit_error %d\n", cookie);
+		ret = -EIO;
+		goto err_unmap;
+	}
+
+	init_completion(dma_completion);
+	dma_async_issue_pending(chan);
+
+	/* Wait DMA to finish the data transfer.*/
+	timeout =
+	wait_for_completion_timeout(dma_completion, msecs_to_jiffies(1000));
+	if (!timeout) {
+		dev_err(lgm_host->dev, "I/O Error in DMA RX (status %d)\n",
+			dmaengine_tx_status(chan, cookie, NULL));
+		dmaengine_terminate_sync(chan);
+		ret = -ETIMEDOUT;
+		goto err_unmap;
+	}
+
+	return 0;
+
+err_unmap:
+	dma_unmap_single(lgm_host->dev, buf_dma, len, dir);
+
+	return ret;
+}
+
+static void lgm_nand_trigger(struct lgm_nand_host *lgm_host, int page, u32 cmd)
+{
+	unsigned int val;
+
+	val = cmd | (page & 0xFF) << NAND_CTL1_ADDR_3_SHIFT;
+	writel(val, lgm_host->hsnand_va + NAND_CTL1);
+	val = (page & 0xFFFF00) >> 8 | NAND_CTL2_CYC_N_V5;
+	writel(val, lgm_host->hsnand_va + NAND_CTL2);
+
+	writel(lgm_host->nd_para0, lgm_host->hsnand_va + NAND_PARA0);
+
+	/* clear first, will update later */
+	writel(0xFFFFFFFF, lgm_host->hsnand_va + NAND_CMSG_0);
+	writel(0xFFFFFFFF, lgm_host->hsnand_va + NAND_CMSG_1);
+
+	writel(NAND_INT_MSK_CTL_WR_C, lgm_host->hsnand_va + NAND_INT_MSK_CTL);
+
+	val = cmd == NAND_CMD_READ0 ? NAND_CTL_RW_READ : NAND_CTL_RW_WRITE;
+
+	writel(NAND_CTL_MSG_EN | NAND_CTL_CKFF_EN | NAND_CTL_ECC_OFF_V8TH |
+	       NAND_CTL_CE_SEL_CS(lgm_host->cs) | NAND_CTL_MODE_ECC |
+	       NAND_CTL_GO | val, lgm_host->hsnand_va + NAND_CTL);
+}
+
+static int lgm_nand_read_page_hwecc(struct nand_chip *chip, u8 *buf,
+				    int oob_required, int page)
+{
+	struct mtd_info *mtd = nand_to_mtd(chip);
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	int ret, x;
+
+	lgm_nand_trigger(lgm_host, page, NAND_CMD_READ0);
+
+	ret = lgm_dma_start(lgm_host, DMA_DEV_TO_MEM, buf, mtd->writesize);
+	if (ret)
+		return ret;
+
+	if (oob_required)
+		chip->ecc.read_oob(chip, page);
+
+	x = readl(lgm_host->hsnand_va + NAND_CTL);
+	x &= ~NAND_CTL_GO;
+	writel(x, lgm_host->hsnand_va + NAND_CTL);
+
+	return 0;
+}
+
+static int lgm_nand_write_page_hwecc(struct nand_chip *chip, const u8 *buf,
+				     int oob_required, int page)
+{
+	struct mtd_info *mtd = nand_to_mtd(chip);
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	void __iomem *int_sta = lgm_host->hsnand_va + NAND_INT_STA;
+	int ret, val, x;
+	__be32 reg;
+
+	lgm_nand_trigger(lgm_host, page, NAND_CMD_SEQIN);
+
+	ret = lgm_dma_start(lgm_host, DMA_MEM_TO_DEV, buf, mtd->writesize);
+	if (ret)
+		return ret;
+
+	if (oob_required) {
+		const u8 *pdata;
+
+		pdata = chip->oob_poi;
+		reg = cpu_to_be32(*pdata++);
+		writel(reg, lgm_host->hsnand_va + NAND_CMSG_0);
+
+		reg = cpu_to_be32(*pdata);
+		writel(reg, lgm_host->hsnand_va + NAND_CMSG_1);
+	}
+
+	ret = readl_poll_timeout_atomic(int_sta, val,
+					!(val & NAND_INT_STA_WR_C), 10, 1000);
+	if (ret)
+		return -EIO;
+
+	x = readl(lgm_host->hsnand_va + NAND_CTL);
+	x &= ~NAND_CTL_GO;
+	writel(x, lgm_host->hsnand_va + NAND_CTL);
+
+	return 0;
+}
+
+static const u8 ecc_strength[] = { 1, 1, 4, 8, 24, 32, 40, 60, };
+
+static int lgm_nand_attach_chip(struct nand_chip *chip)
+{
+	struct mtd_info *mtd = nand_to_mtd(chip);
+	struct lgm_nand_host *lgm_host = nand_get_controller_data(chip);
+	u32 eccsize, eccsteps, eccbytes, ecctotal, pagesize, pg_per_blk;
+	u32 eccstrength = chip->ecc.strength;
+	u32 writesize = mtd->writesize;
+	u32 blocksize = mtd->erasesize;
+	int start, val, i;
+
+	if (chip->ecc.mode != NAND_ECC_HW)
+		return 0;
+
+	/* Check whether eccsize is 0x0 or wrong. assign eccsize = 512 if YES */
+	if (!chip->ecc.size)
+		chip->ecc.size = 512;
+	eccsize = chip->ecc.size;
+
+	switch (eccsize) {
+	case 512:
+		start = 1;
+		if (!eccstrength)
+			eccstrength = 4;
+		break;
+	case 1024:
+		start = 4;
+		if (!eccstrength)
+			eccstrength = 32;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	i = round_up(start + 1, 4);
+	for (val = start; val < i; val++) {
+		if (eccstrength == ecc_strength[val])
+			break;
+	}
+	if (val == i)
+		return -EINVAL;
+
+	if (eccstrength == 8)
+		eccbytes = 14;
+	else
+		eccbytes = DIV_ROUND_UP(eccstrength * fls(8 * eccsize), 8);
+
+	eccsteps = writesize / eccsize;
+	ecctotal = eccsteps * eccbytes;
+	if ((ecctotal + 8) > mtd->oobsize)
+		return -ERANGE;
+
+	chip->ecc.total = ecctotal;
+	pagesize = fls(writesize >> 11);
+	if (pagesize > NAND_PARA0_PAGE_V8192)
+		return -ERANGE;
+
+	pg_per_blk = fls((blocksize / writesize) >> 6) << 4;
+	if (pg_per_blk > NAND_PARA0_PIB_V256)
+		return -ERANGE;
+
+	lgm_host->nd_para0 = pagesize | pg_per_blk | NAND_PARA0_BYP_EN_NP |
+			     NAND_PARA0_BYP_DEC_NP | NAND_PARA0_ADEP_EN |
+			     NAND_PARA0_TYPE_ONFI | (val << 29);
+
+	mtd_set_ooblayout(mtd, &lgm_nand_ooblayout_ops);
+	chip->ecc.read_page = lgm_nand_read_page_hwecc;
+	chip->ecc.write_page = lgm_nand_write_page_hwecc;
+
+	return 0;
+}
+
+static const struct nand_controller_ops lgm_nand_controller_ops = {
+	.attach_chip = lgm_nand_attach_chip,
+};
+
+static void lgm_dma_exit(struct lgm_nand_host *lgm_host)
+{
+	if (lgm_host->dma_rx) {
+		dma_release_channel(lgm_host->dma_rx);
+		lgm_host->dma_rx = NULL;
+	}
+
+	if (lgm_host->dma_tx) {
+		dma_release_channel(lgm_host->dma_tx);
+		lgm_host->dma_tx = NULL;
+	}
+}
+
+static int lgm_dma_init(struct device *dev, struct lgm_nand_host *lgm_host)
+{
+	int ret;
+
+	/* Prepare for TX DMA: */
+	lgm_host->dma_tx = dma_request_chan(dev, "tx");
+	if (IS_ERR(lgm_host->dma_tx)) {
+		ret = PTR_ERR(lgm_host->dma_tx);
+		dev_err(dev, "can't get the TX DMA channel, error %d!\n", ret);
+		goto err;
+	}
+
+	/* Prepare for RX: */
+	lgm_host->dma_rx = dma_request_chan(dev, "rx");
+	if (IS_ERR(lgm_host->dma_rx)) {
+		ret = PTR_ERR(lgm_host->dma_rx);
+		dev_err(dev, "can't get the RX DMA channel, error %d\n", ret);
+		goto err;
+	}
+
+	return 0;
+err:
+	return ret;
+}
+
+static int lgm_nand_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct lgm_nand_host *lgm_host;
+	phys_addr_t nandaddr_pa;
+	struct mtd_info *mtd;
+	struct resource *res;
+	int ret;
+	u32 cs;
+
+	lgm_host = devm_kzalloc(dev, sizeof(*lgm_host), GFP_KERNEL);
+	if (!lgm_host)
+		return -ENOMEM;
+
+	lgm_host->lgm_va = devm_platform_ioremap_resource_byname(pdev, "lgmnand");
+	if (IS_ERR(lgm_host->lgm_va))
+		return PTR_ERR(lgm_host->lgm_va);
+
+	lgm_host->hsnand_va = devm_platform_ioremap_resource_byname(pdev, "hsnand");
+	if (IS_ERR(lgm_host->hsnand_va))
+		return PTR_ERR(lgm_host->hsnand_va);
+
+	ret = device_property_read_u32(dev, "nand,cs", &cs);
+	if (ret) {
+		dev_err(dev, "failed to get chip select: %d\n", ret);
+		return ret;
+	}
+
+	lgm_host->cs = cs;
+
+	lgm_host->cs_name = devm_kasprintf(dev, GFP_KERNEL, "nand_cs%d", cs);
+	if (IS_ERR(lgm_host->cs_name)) {
+		ret = PTR_ERR(lgm_host->cs_name);
+		dev_err(dev, "failed to get chip select name: %d\n", ret);
+		return ret;
+	}
+
+	res = devm_platform_ioremap_resource_byname(pdev, lgm_host->cs_name);
+	lgm_host->nandaddr_va = res;
+	nandaddr_pa = res->start;
+	if (IS_ERR(lgm_host->nandaddr_va))
+		return PTR_ERR(lgm_host->nandaddr_va);
+
+	lgm_host->clk = devm_clk_get(dev, NULL);
+	if (IS_ERR(lgm_host->clk)) {
+		ret = PTR_ERR(lgm_host->clk);
+		dev_err(dev, "failed to get clock: %d\n", ret);
+		return ret;
+	}
+
+	ret = clk_prepare_enable(lgm_host->clk);
+	if (ret) {
+		dev_err(dev, "failed to enable clock: %d\n", ret);
+		return ret;
+	}
+	lgm_host->clk_rate = clk_get_rate(lgm_host->clk);
+
+	ret = lgm_dma_init(dev, lgm_host);
+	if (ret)
+		goto disable_clk;
+
+	writel(lower_32_bits(nandaddr_pa) | LGM_ADDR_SEL_REGEN | LGM_ADDR_MASK,
+	       lgm_host->lgm_va + LGM_ADDR_SEL(cs));
+
+	writel(LGM_BUSCON_CMULT_V4 | LGM_BUSCON_RECOVC(1) |
+	       LGM_BUSCON_HOLDC(1) | LGM_BUSCON_WAITRDC(2) |
+	       LGM_BUSCON_WAITWRC(2) | LGM_BUSCON_BCGEN_CS | LGM_BUSCON_ALEC |
+	       LGM_BUSCON_SETUP_EN, lgm_host->lgm_va + LGM_BUSCON(cs));
+
+	/*
+	 * NAND physical address selection is based on the chip select
+	 * and written to ADDR_SEL register to get Memory Region Base address.
+	 * FPI Bus addresses are compared to this base address in conjunction
+	 * with the mask control. Driver need to program this field!
+	 * Address: 0x17400 if chip select is CS_0
+	 * Address: 0x17C00 if chip select is CS_1
+	 * Refer the Intel LGM SoC datasheet.
+	 */
+	writel(0x17400051, lgm_host->lgm_va + LGM_ADDR_SEL(0));
+	writel(0x17C00051, lgm_host->lgm_va + LGM_ADDR_SEL(cs));
+	nand_set_flash_node(&lgm_host->chip, dev->of_node);
+	mtd = nand_to_mtd(&lgm_host->chip);
+	mtd->dev.parent = dev;
+	lgm_host->dev = dev;
+
+	platform_set_drvdata(pdev, lgm_host);
+	nand_set_controller_data(&lgm_host->chip, lgm_host);
+
+	lgm_host->chip.legacy.read_byte = lgm_read_byte;
+	lgm_host->chip.legacy.read_buf = lgm_read_buf;
+	lgm_host->chip.legacy.write_buf = lgm_write_buf;
+	lgm_host->chip.legacy.select_chip = lgm_select_chip;
+	lgm_host->chip.legacy.dev_ready = lgm_dev_ready;
+	lgm_host->chip.legacy.cmd_ctrl = lgm_cmd_ctrl;
+	lgm_host->chip.legacy.chip_delay = 30;
+	lgm_host->chip.legacy.dummy_controller.ops = &lgm_nand_controller_ops;
+
+	/* Scan to find existence of the device */
+	ret = nand_scan(&lgm_host->chip, 1);
+	if (ret)
+		goto exit_dma;
+
+	ret = mtd_device_register(mtd, NULL, 0);
+	if (ret)
+		goto clean_nand;
+
+	return 0;
+
+clean_nand:
+	nand_cleanup(&lgm_host->chip);
+exit_dma:
+	lgm_dma_exit(lgm_host);
+disable_clk:
+	clk_disable_unprepare(lgm_host->clk);
+
+	return ret;
+}
+
+static int lgm_nand_remove(struct platform_device *pdev)
+{
+	struct lgm_nand_host *lgm_host = platform_get_drvdata(pdev);
+
+	nand_release(&lgm_host->chip);
+	clk_disable_unprepare(lgm_host->clk);
+	lgm_dma_exit(lgm_host);
+
+	return 0;
+}
+
+static const struct of_device_id lgm_nand_match[] = {
+	{ .compatible = "intel,lgm-nand", },
+	{}
+};
+MODULE_DEVICE_TABLE(of, lgm_nand_match);
+
+static struct platform_driver lgm_nand_driver = {
+	.probe = lgm_nand_probe,
+	.remove = lgm_nand_remove,
+	.driver = {
+		.name = "intel-lgm-nand",
+		.of_match_table = lgm_nand_match,
+	},
+
+};
+module_platform_driver(lgm_nand_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Vadivel Murugan R <vadivel.muruganx.ramuthevar@intel.com>");
+MODULE_DESCRIPTION("Intel's LGM External Bus NAND Controller driver");
-- 
2.11.0


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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

Hello Ramuthevar,

On Tue, 14 Apr 2020 10:24:33 +0800
"Ramuthevar,Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> +	lgm_host->chip.legacy.read_byte = lgm_read_byte;
> +	lgm_host->chip.legacy.read_buf = lgm_read_buf;
> +	lgm_host->chip.legacy.write_buf = lgm_write_buf;
> +	lgm_host->chip.legacy.select_chip = lgm_select_chip;
> +	lgm_host->chip.legacy.dev_ready = lgm_dev_ready;
> +	lgm_host->chip.legacy.cmd_ctrl = lgm_cmd_ctrl;
> +	lgm_host->chip.legacy.chip_delay = 30;
> +	lgm_host->chip.legacy.dummy_controller.ops = &lgm_nand_controller_ops;
> +

Seriously, what's not clear in [1]? Okay, let's say you overlooked this
comment, isn't the name of the field explicit enough? We received a
few other drivers implementing the legacy interface in the last few
months so maybe there's something to improve on our end (update the
doc, move legacy drivers to a legacy sub-dir?).

Back to more constructive comment now: please implement ->exec_op() to
replace those legacy hooks.

Regards,

Boris

[1]https://elixir.bootlin.com/linux/v5.7-rc1/source/include/linux/mtd/rawnand.h#L987

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

Hello Ramuthevar,

On Tue, 14 Apr 2020 10:24:33 +0800
"Ramuthevar,Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> +	lgm_host->chip.legacy.read_byte = lgm_read_byte;
> +	lgm_host->chip.legacy.read_buf = lgm_read_buf;
> +	lgm_host->chip.legacy.write_buf = lgm_write_buf;
> +	lgm_host->chip.legacy.select_chip = lgm_select_chip;
> +	lgm_host->chip.legacy.dev_ready = lgm_dev_ready;
> +	lgm_host->chip.legacy.cmd_ctrl = lgm_cmd_ctrl;
> +	lgm_host->chip.legacy.chip_delay = 30;
> +	lgm_host->chip.legacy.dummy_controller.ops = &lgm_nand_controller_ops;
> +

Seriously, what's not clear in [1]? Okay, let's say you overlooked this
comment, isn't the name of the field explicit enough? We received a
few other drivers implementing the legacy interface in the last few
months so maybe there's something to improve on our end (update the
doc, move legacy drivers to a legacy sub-dir?).

Back to more constructive comment now: please implement ->exec_op() to
replace those legacy hooks.

Regards,

Boris

[1]https://elixir.bootlin.com/linux/v5.7-rc1/source/include/linux/mtd/rawnand.h#L987

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

     Thank you so much for review comments and your time...

On 14/4/2020 3:21 pm, Boris Brezillon wrote:
> Hello Ramuthevar,
>
> On Tue, 14 Apr 2020 10:24:33 +0800
> "Ramuthevar,Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> +	lgm_host->chip.legacy.read_byte = lgm_read_byte;
>> +	lgm_host->chip.legacy.read_buf = lgm_read_buf;
>> +	lgm_host->chip.legacy.write_buf = lgm_write_buf;
>> +	lgm_host->chip.legacy.select_chip = lgm_select_chip;
>> +	lgm_host->chip.legacy.dev_ready = lgm_dev_ready;
>> +	lgm_host->chip.legacy.cmd_ctrl = lgm_cmd_ctrl;
>> +	lgm_host->chip.legacy.chip_delay = 30;
>> +	lgm_host->chip.legacy.dummy_controller.ops = &lgm_nand_controller_ops;
>> +
> Seriously, what's not clear in [1]? Okay, let's say you overlooked this
> comment, isn't the name of the field explicit enough? We received a
> few other drivers implementing the legacy interface in the last few
> months so maybe there's something to improve on our end (update the
> doc, move legacy drivers to a legacy sub-dir?).
Understood the legacy to latest implementation based ->exec_op(), Thanks!
>
> Back to more constructive comment now: please implement ->exec_op() to
> replace those legacy hooks.

Agreed, will do the implementation of exec_op() hook and update the patches.

Regards
Vadivel
>
> Regards,
>
> Boris
>
> [1]https://elixir.bootlin.com/linux/v5.7-rc1/source/include/linux/mtd/rawnand.h#L987

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

     Thank you so much for review comments and your time...

On 14/4/2020 3:21 pm, Boris Brezillon wrote:
> Hello Ramuthevar,
>
> On Tue, 14 Apr 2020 10:24:33 +0800
> "Ramuthevar,Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> +	lgm_host->chip.legacy.read_byte = lgm_read_byte;
>> +	lgm_host->chip.legacy.read_buf = lgm_read_buf;
>> +	lgm_host->chip.legacy.write_buf = lgm_write_buf;
>> +	lgm_host->chip.legacy.select_chip = lgm_select_chip;
>> +	lgm_host->chip.legacy.dev_ready = lgm_dev_ready;
>> +	lgm_host->chip.legacy.cmd_ctrl = lgm_cmd_ctrl;
>> +	lgm_host->chip.legacy.chip_delay = 30;
>> +	lgm_host->chip.legacy.dummy_controller.ops = &lgm_nand_controller_ops;
>> +
> Seriously, what's not clear in [1]? Okay, let's say you overlooked this
> comment, isn't the name of the field explicit enough? We received a
> few other drivers implementing the legacy interface in the last few
> months so maybe there's something to improve on our end (update the
> doc, move legacy drivers to a legacy sub-dir?).
Understood the legacy to latest implementation based ->exec_op(), Thanks!
>
> Back to more constructive comment now: please implement ->exec_op() to
> replace those legacy hooks.

Agreed, will do the implementation of exec_op() hook and update the patches.

Regards
Vadivel
>
> Regards,
>
> Boris
>
> [1]https://elixir.bootlin.com/linux/v5.7-rc1/source/include/linux/mtd/rawnand.h#L987

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

RE: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Martin Blumenstingl]

Hi,

first of all: thank you for working on upstreaming this.
Especially since you are going to use the new exec_op style in v2 as
Boris suggested.

> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> 
> This patch adds the new IP of Nand Flash Controller(NFC) support
> on Intel's Lightning Mountain(LGM) SoC.
> 
> DMA is used for burst data transfer operation, also DMA HW supports
> aligned 32bit memory address and aligned data access by default.
> DMA burst of 8 supported. Data register used to support the read/write
> operation from/to device.
I am wondering how this new hardware is different from the Lantiq NAND
controller IP - for which there is already a driver in mainline (it's
in drivers/mtd/nand/raw/xway_nand.c).
The CON and WAIT registers look suspiciously similar.

As far as I understand the "old" SoCs (VRX200 and earlier) don't have
a built-in ECC engine. This seems to have changed with ARX300 though
(again, AFAIK).

A bit of lineage on these SoCs (initially these were developed by
Infineon. Lantiq then started as an Infineon spin-off in 2009 and
was then acquired by Intel in 2015):
- Danube
- ARX100 from 2008/2009
- VRX200 from 2009/2010
- ARX300 from 2014
- GRX350 from 2015/2016
- GRX550 from 2017
- and now finally: LGM from 2020 (est.)

The existing xway_nand driver supports the Danube, ARX100 and VRX200
SoCs.


Best regards,
Martin

RE: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Martin Blumenstingl]

Hi,

first of all: thank you for working on upstreaming this.
Especially since you are going to use the new exec_op style in v2 as
Boris suggested.

> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> 
> This patch adds the new IP of Nand Flash Controller(NFC) support
> on Intel's Lightning Mountain(LGM) SoC.
> 
> DMA is used for burst data transfer operation, also DMA HW supports
> aligned 32bit memory address and aligned data access by default.
> DMA burst of 8 supported. Data register used to support the read/write
> operation from/to device.
I am wondering how this new hardware is different from the Lantiq NAND
controller IP - for which there is already a driver in mainline (it's
in drivers/mtd/nand/raw/xway_nand.c).
The CON and WAIT registers look suspiciously similar.

As far as I understand the "old" SoCs (VRX200 and earlier) don't have
a built-in ECC engine. This seems to have changed with ARX300 though
(again, AFAIK).

A bit of lineage on these SoCs (initially these were developed by
Infineon. Lantiq then started as an Infineon spin-off in 2009 and
was then acquired by Intel in 2015):
- Danube
- ARX100 from 2008/2009
- VRX200 from 2009/2010
- ARX300 from 2014
- GRX350 from 2015/2016
- GRX550 from 2017
- and now finally: LGM from 2020 (est.)

The existing xway_nand driver supports the Danube, ARX100 and VRX200
SoCs.


Best regards,
Martin

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Martin,

     Thank you so much for review comments and your time...

On 16/4/2020 6:05 am, Martin Blumenstingl wrote:
> Hi,
>
> first of all: thank you for working on upstreaming this.
> Especially since you are going to use the new exec_op style in v2 as
> Boris suggested.
>
>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>
>> This patch adds the new IP of Nand Flash Controller(NFC) support
>> on Intel's Lightning Mountain(LGM) SoC.
>>
>> DMA is used for burst data transfer operation, also DMA HW supports
>> aligned 32bit memory address and aligned data access by default.
>> DMA burst of 8 supported. Data register used to support the read/write
>> operation from/to device.
> I am wondering how this new hardware is different from the Lantiq NAND
> controller IP - for which there is already a driver in mainline (it's
> in drivers/mtd/nand/raw/xway_nand.c).
> The CON and WAIT registers look suspiciously similar.
>
> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
> a built-in ECC engine. This seems to have changed with ARX300 though
> (again, AFAIK).
>
> A bit of lineage on these SoCs (initially these were developed by
> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
> was then acquired by Intel in 2015):
> - Danube
> - ARX100 from 2008/2009
> - VRX200 from 2009/2010
> - ARX300 from 2014
> - GRX350 from 2015/2016
> - GRX550 from 2017
> - and now finally: LGM from 2020 (est.)
>
> The existing xway_nand driver supports the Danube, ARX100 and VRX200
> SoCs.
Lantiq upstreamed a driver for an older version of this IP core 8 years 
ago, see here:
https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c 
It does not support DMA and ECC.
This upstream driver works with the xrx200, I do not know how well it 
works with other SoCs.

Regards
Vadivel
>
>
> Best regards,
> Martin

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Martin,

     Thank you so much for review comments and your time...

On 16/4/2020 6:05 am, Martin Blumenstingl wrote:
> Hi,
>
> first of all: thank you for working on upstreaming this.
> Especially since you are going to use the new exec_op style in v2 as
> Boris suggested.
>
>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>
>> This patch adds the new IP of Nand Flash Controller(NFC) support
>> on Intel's Lightning Mountain(LGM) SoC.
>>
>> DMA is used for burst data transfer operation, also DMA HW supports
>> aligned 32bit memory address and aligned data access by default.
>> DMA burst of 8 supported. Data register used to support the read/write
>> operation from/to device.
> I am wondering how this new hardware is different from the Lantiq NAND
> controller IP - for which there is already a driver in mainline (it's
> in drivers/mtd/nand/raw/xway_nand.c).
> The CON and WAIT registers look suspiciously similar.
>
> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
> a built-in ECC engine. This seems to have changed with ARX300 though
> (again, AFAIK).
>
> A bit of lineage on these SoCs (initially these were developed by
> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
> was then acquired by Intel in 2015):
> - Danube
> - ARX100 from 2008/2009
> - VRX200 from 2009/2010
> - ARX300 from 2014
> - GRX350 from 2015/2016
> - GRX550 from 2017
> - and now finally: LGM from 2020 (est.)
>
> The existing xway_nand driver supports the Danube, ARX100 and VRX200
> SoCs.
Lantiq upstreamed a driver for an older version of this IP core 8 years 
ago, see here:
https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c 
It does not support DMA and ECC.
This upstream driver works with the xrx200, I do not know how well it 
works with other SoCs.

Regards
Vadivel
>
>
> Best regards,
> Martin

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 17:35:26 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> Hi Martin,
> 
>      Thank you so much for review comments and your time...
> 
> On 16/4/2020 6:05 am, Martin Blumenstingl wrote:
> > Hi,
> >
> > first of all: thank you for working on upstreaming this.
> > Especially since you are going to use the new exec_op style in v2 as
> > Boris suggested.
> >  
> >> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> >>
> >> This patch adds the new IP of Nand Flash Controller(NFC) support
> >> on Intel's Lightning Mountain(LGM) SoC.
> >>
> >> DMA is used for burst data transfer operation, also DMA HW supports
> >> aligned 32bit memory address and aligned data access by default.
> >> DMA burst of 8 supported. Data register used to support the read/write
> >> operation from/to device.  
> > I am wondering how this new hardware is different from the Lantiq NAND
> > controller IP - for which there is already a driver in mainline (it's
> > in drivers/mtd/nand/raw/xway_nand.c).
> > The CON and WAIT registers look suspiciously similar.
> >
> > As far as I understand the "old" SoCs (VRX200 and earlier) don't have
> > a built-in ECC engine. This seems to have changed with ARX300 though
> > (again, AFAIK).
> >
> > A bit of lineage on these SoCs (initially these were developed by
> > Infineon. Lantiq then started as an Infineon spin-off in 2009 and
> > was then acquired by Intel in 2015):
> > - Danube
> > - ARX100 from 2008/2009
> > - VRX200 from 2009/2010
> > - ARX300 from 2014
> > - GRX350 from 2015/2016
> > - GRX550 from 2017
> > - and now finally: LGM from 2020 (est.)
> >
> > The existing xway_nand driver supports the Danube, ARX100 and VRX200
> > SoCs.  
> Lantiq upstreamed a driver for an older version of this IP core 8 years 
> ago, see here:
> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c 
> It does not support DMA and ECC.

Then let's just extend this driver to support the new features. Plus,
we'll be happy to have one more of the existing driver converted to
->exec_op() ;-).

> This upstream driver works with the xrx200, I do not know how well it 
> works with other SoCs.
> 
> Regards
> Vadivel
> >
> >
> > Best regards,
> > Martin  

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 17:35:26 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> Hi Martin,
> 
>      Thank you so much for review comments and your time...
> 
> On 16/4/2020 6:05 am, Martin Blumenstingl wrote:
> > Hi,
> >
> > first of all: thank you for working on upstreaming this.
> > Especially since you are going to use the new exec_op style in v2 as
> > Boris suggested.
> >  
> >> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> >>
> >> This patch adds the new IP of Nand Flash Controller(NFC) support
> >> on Intel's Lightning Mountain(LGM) SoC.
> >>
> >> DMA is used for burst data transfer operation, also DMA HW supports
> >> aligned 32bit memory address and aligned data access by default.
> >> DMA burst of 8 supported. Data register used to support the read/write
> >> operation from/to device.  
> > I am wondering how this new hardware is different from the Lantiq NAND
> > controller IP - for which there is already a driver in mainline (it's
> > in drivers/mtd/nand/raw/xway_nand.c).
> > The CON and WAIT registers look suspiciously similar.
> >
> > As far as I understand the "old" SoCs (VRX200 and earlier) don't have
> > a built-in ECC engine. This seems to have changed with ARX300 though
> > (again, AFAIK).
> >
> > A bit of lineage on these SoCs (initially these were developed by
> > Infineon. Lantiq then started as an Infineon spin-off in 2009 and
> > was then acquired by Intel in 2015):
> > - Danube
> > - ARX100 from 2008/2009
> > - VRX200 from 2009/2010
> > - ARX300 from 2014
> > - GRX350 from 2015/2016
> > - GRX550 from 2017
> > - and now finally: LGM from 2020 (est.)
> >
> > The existing xway_nand driver supports the Danube, ARX100 and VRX200
> > SoCs.  
> Lantiq upstreamed a driver for an older version of this IP core 8 years 
> ago, see here:
> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c 
> It does not support DMA and ECC.

Then let's just extend this driver to support the new features. Plus,
we'll be happy to have one more of the existing driver converted to
->exec_op() ;-).

> This upstream driver works with the xrx200, I do not know how well it 
> works with other SoCs.
> 
> Regards
> Vadivel
> >
> >
> > Best regards,
> > Martin  


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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

     Thank you for prompt reply...

On 16/4/2020 5:38 pm, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 17:35:26 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> Hi Martin,
>>
>>       Thank you so much for review comments and your time...
>>
>> On 16/4/2020 6:05 am, Martin Blumenstingl wrote:
>>> Hi,
>>>
>>> first of all: thank you for working on upstreaming this.
>>> Especially since you are going to use the new exec_op style in v2 as
>>> Boris suggested.
>>>   
>>>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>>>
>>>> This patch adds the new IP of Nand Flash Controller(NFC) support
>>>> on Intel's Lightning Mountain(LGM) SoC.
>>>>
>>>> DMA is used for burst data transfer operation, also DMA HW supports
>>>> aligned 32bit memory address and aligned data access by default.
>>>> DMA burst of 8 supported. Data register used to support the read/write
>>>> operation from/to device.
>>> I am wondering how this new hardware is different from the Lantiq NAND
>>> controller IP - for which there is already a driver in mainline (it's
>>> in drivers/mtd/nand/raw/xway_nand.c).
>>> The CON and WAIT registers look suspiciously similar.
>>>
>>> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
>>> a built-in ECC engine. This seems to have changed with ARX300 though
>>> (again, AFAIK).
>>>
>>> A bit of lineage on these SoCs (initially these were developed by
>>> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
>>> was then acquired by Intel in 2015):
>>> - Danube
>>> - ARX100 from 2008/2009
>>> - VRX200 from 2009/2010
>>> - ARX300 from 2014
>>> - GRX350 from 2015/2016
>>> - GRX550 from 2017
>>> - and now finally: LGM from 2020 (est.)
>>>
>>> The existing xway_nand driver supports the Danube, ARX100 and VRX200
>>> SoCs.
>> Lantiq upstreamed a driver for an older version of this IP core 8 years
>> ago, see here:
>> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c
>> It does not support DMA and ECC.
> Then let's just extend this driver to support the new features. Plus,
We do not have the platform to test also it's very old legacy driver .
> we'll be happy to have one more of the existing driver converted to
> ->exec_op() ;-).

I have completely adapted to ->exec_op() hook up to replace the legacy 
call-back.

Regards
Vadivel
>
>> This upstream driver works with the xrx200, I do not know how well it
>> works with other SoCs.
>>
>> Regards
>> Vadivel
>>>
>>> Best regards,
>>> Martin

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

     Thank you for prompt reply...

On 16/4/2020 5:38 pm, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 17:35:26 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> Hi Martin,
>>
>>       Thank you so much for review comments and your time...
>>
>> On 16/4/2020 6:05 am, Martin Blumenstingl wrote:
>>> Hi,
>>>
>>> first of all: thank you for working on upstreaming this.
>>> Especially since you are going to use the new exec_op style in v2 as
>>> Boris suggested.
>>>   
>>>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>>>
>>>> This patch adds the new IP of Nand Flash Controller(NFC) support
>>>> on Intel's Lightning Mountain(LGM) SoC.
>>>>
>>>> DMA is used for burst data transfer operation, also DMA HW supports
>>>> aligned 32bit memory address and aligned data access by default.
>>>> DMA burst of 8 supported. Data register used to support the read/write
>>>> operation from/to device.
>>> I am wondering how this new hardware is different from the Lantiq NAND
>>> controller IP - for which there is already a driver in mainline (it's
>>> in drivers/mtd/nand/raw/xway_nand.c).
>>> The CON and WAIT registers look suspiciously similar.
>>>
>>> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
>>> a built-in ECC engine. This seems to have changed with ARX300 though
>>> (again, AFAIK).
>>>
>>> A bit of lineage on these SoCs (initially these were developed by
>>> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
>>> was then acquired by Intel in 2015):
>>> - Danube
>>> - ARX100 from 2008/2009
>>> - VRX200 from 2009/2010
>>> - ARX300 from 2014
>>> - GRX350 from 2015/2016
>>> - GRX550 from 2017
>>> - and now finally: LGM from 2020 (est.)
>>>
>>> The existing xway_nand driver supports the Danube, ARX100 and VRX200
>>> SoCs.
>> Lantiq upstreamed a driver for an older version of this IP core 8 years
>> ago, see here:
>> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c
>> It does not support DMA and ECC.
> Then let's just extend this driver to support the new features. Plus,
We do not have the platform to test also it's very old legacy driver .
> we'll be happy to have one more of the existing driver converted to
> ->exec_op() ;-).

I have completely adapted to ->exec_op() hook up to replace the legacy 
call-back.

Regards
Vadivel
>
>> This upstream driver works with the xrx200, I do not know how well it
>> works with other SoCs.
>>
>> Regards
>> Vadivel
>>>
>>> Best regards,
>>> Martin

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 17:45:49 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> >>>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> >>>>
> >>>> This patch adds the new IP of Nand Flash Controller(NFC) support
> >>>> on Intel's Lightning Mountain(LGM) SoC.
> >>>>
> >>>> DMA is used for burst data transfer operation, also DMA HW supports
> >>>> aligned 32bit memory address and aligned data access by default.
> >>>> DMA burst of 8 supported. Data register used to support the read/write
> >>>> operation from/to device.  
> >>> I am wondering how this new hardware is different from the Lantiq NAND
> >>> controller IP - for which there is already a driver in mainline (it's
> >>> in drivers/mtd/nand/raw/xway_nand.c).
> >>> The CON and WAIT registers look suspiciously similar.
> >>>
> >>> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
> >>> a built-in ECC engine. This seems to have changed with ARX300 though
> >>> (again, AFAIK).
> >>>
> >>> A bit of lineage on these SoCs (initially these were developed by
> >>> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
> >>> was then acquired by Intel in 2015):
> >>> - Danube
> >>> - ARX100 from 2008/2009
> >>> - VRX200 from 2009/2010
> >>> - ARX300 from 2014
> >>> - GRX350 from 2015/2016
> >>> - GRX550 from 2017
> >>> - and now finally: LGM from 2020 (est.)
> >>>
> >>> The existing xway_nand driver supports the Danube, ARX100 and VRX200
> >>> SoCs.  
> >> Lantiq upstreamed a driver for an older version of this IP core 8 years
> >> ago, see here:
> >> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c
> >> It does not support DMA and ECC.  
> > Then let's just extend this driver to support the new features. Plus,  
> We do not have the platform to test also it's very old legacy driver .

Well, if it's similar enough, we want to have one driver.

> > we'll be happy to have one more of the existing driver converted to  
> > ->exec_op() ;-).  
> 
> I have completely adapted to ->exec_op() hook up to replace the legacy 
> call-back.

I suspect porting what you've done to the xway driver shouldn't be too
complicated.

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 17:45:49 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> >>>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> >>>>
> >>>> This patch adds the new IP of Nand Flash Controller(NFC) support
> >>>> on Intel's Lightning Mountain(LGM) SoC.
> >>>>
> >>>> DMA is used for burst data transfer operation, also DMA HW supports
> >>>> aligned 32bit memory address and aligned data access by default.
> >>>> DMA burst of 8 supported. Data register used to support the read/write
> >>>> operation from/to device.  
> >>> I am wondering how this new hardware is different from the Lantiq NAND
> >>> controller IP - for which there is already a driver in mainline (it's
> >>> in drivers/mtd/nand/raw/xway_nand.c).
> >>> The CON and WAIT registers look suspiciously similar.
> >>>
> >>> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
> >>> a built-in ECC engine. This seems to have changed with ARX300 though
> >>> (again, AFAIK).
> >>>
> >>> A bit of lineage on these SoCs (initially these were developed by
> >>> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
> >>> was then acquired by Intel in 2015):
> >>> - Danube
> >>> - ARX100 from 2008/2009
> >>> - VRX200 from 2009/2010
> >>> - ARX300 from 2014
> >>> - GRX350 from 2015/2016
> >>> - GRX550 from 2017
> >>> - and now finally: LGM from 2020 (est.)
> >>>
> >>> The existing xway_nand driver supports the Danube, ARX100 and VRX200
> >>> SoCs.  
> >> Lantiq upstreamed a driver for an older version of this IP core 8 years
> >> ago, see here:
> >> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c
> >> It does not support DMA and ECC.  
> > Then let's just extend this driver to support the new features. Plus,  
> We do not have the platform to test also it's very old legacy driver .

Well, if it's similar enough, we want to have one driver.

> > we'll be happy to have one more of the existing driver converted to  
> > ->exec_op() ;-).  
> 
> I have completely adapted to ->exec_op() hook up to replace the legacy 
> call-back.

I suspect porting what you've done to the xway driver shouldn't be too
complicated.

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

On 16/4/2020 6:26 pm, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 17:45:49 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>>>>>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>>>>>
>>>>>> This patch adds the new IP of Nand Flash Controller(NFC) support
>>>>>> on Intel's Lightning Mountain(LGM) SoC.
>>>>>>
>>>>>> DMA is used for burst data transfer operation, also DMA HW supports
>>>>>> aligned 32bit memory address and aligned data access by default.
>>>>>> DMA burst of 8 supported. Data register used to support the read/write
>>>>>> operation from/to device.
>>>>> I am wondering how this new hardware is different from the Lantiq NAND
>>>>> controller IP - for which there is already a driver in mainline (it's
>>>>> in drivers/mtd/nand/raw/xway_nand.c).
>>>>> The CON and WAIT registers look suspiciously similar.
>>>>>
>>>>> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
>>>>> a built-in ECC engine. This seems to have changed with ARX300 though
>>>>> (again, AFAIK).
>>>>>
>>>>> A bit of lineage on these SoCs (initially these were developed by
>>>>> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
>>>>> was then acquired by Intel in 2015):
>>>>> - Danube
>>>>> - ARX100 from 2008/2009
>>>>> - VRX200 from 2009/2010
>>>>> - ARX300 from 2014
>>>>> - GRX350 from 2015/2016
>>>>> - GRX550 from 2017
>>>>> - and now finally: LGM from 2020 (est.)
>>>>>
>>>>> The existing xway_nand driver supports the Danube, ARX100 and VRX200
>>>>> SoCs.
>>>> Lantiq upstreamed a driver for an older version of this IP core 8 years
>>>> ago, see here:
>>>> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c
>>>> It does not support DMA and ECC.
>>> Then let's just extend this driver to support the new features. Plus,
>> We do not have the platform to test also it's very old legacy driver .
> Well, if it's similar enough, we want to have one driver.

Thank you very much for the time and suggestions...

This in-review driver is written for a new nand flash controller IP 
which is used in LGM.

>>> we'll be happy to have one more of the existing driver converted to
>>> ->exec_op() ;-).
>> I have completely adapted to ->exec_op() hook up to replace the legacy
>> call-back.
> I suspect porting what you've done to the xway driver shouldn't be too
> complicated.
Not ported from xway_nand.c driver , we have developed from the scratch 
to make it work on
Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely 
different and most of the registers won't match.
if we port then it would be ugly and also what are the problem may occur 
we do not know.

Regards
Vadivel

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

On 16/4/2020 6:26 pm, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 17:45:49 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>>>>>> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>>>>>>
>>>>>> This patch adds the new IP of Nand Flash Controller(NFC) support
>>>>>> on Intel's Lightning Mountain(LGM) SoC.
>>>>>>
>>>>>> DMA is used for burst data transfer operation, also DMA HW supports
>>>>>> aligned 32bit memory address and aligned data access by default.
>>>>>> DMA burst of 8 supported. Data register used to support the read/write
>>>>>> operation from/to device.
>>>>> I am wondering how this new hardware is different from the Lantiq NAND
>>>>> controller IP - for which there is already a driver in mainline (it's
>>>>> in drivers/mtd/nand/raw/xway_nand.c).
>>>>> The CON and WAIT registers look suspiciously similar.
>>>>>
>>>>> As far as I understand the "old" SoCs (VRX200 and earlier) don't have
>>>>> a built-in ECC engine. This seems to have changed with ARX300 though
>>>>> (again, AFAIK).
>>>>>
>>>>> A bit of lineage on these SoCs (initially these were developed by
>>>>> Infineon. Lantiq then started as an Infineon spin-off in 2009 and
>>>>> was then acquired by Intel in 2015):
>>>>> - Danube
>>>>> - ARX100 from 2008/2009
>>>>> - VRX200 from 2009/2010
>>>>> - ARX300 from 2014
>>>>> - GRX350 from 2015/2016
>>>>> - GRX550 from 2017
>>>>> - and now finally: LGM from 2020 (est.)
>>>>>
>>>>> The existing xway_nand driver supports the Danube, ARX100 and VRX200
>>>>> SoCs.
>>>> Lantiq upstreamed a driver for an older version of this IP core 8 years
>>>> ago, see here:
>>>> https://elixir.bootlin.com/linux/v5.5.6/source/drivers/mtd/nand/raw/xway_nand.c
>>>> It does not support DMA and ECC.
>>> Then let's just extend this driver to support the new features. Plus,
>> We do not have the platform to test also it's very old legacy driver .
> Well, if it's similar enough, we want to have one driver.

Thank you very much for the time and suggestions...

This in-review driver is written for a new nand flash controller IP 
which is used in LGM.

>>> we'll be happy to have one more of the existing driver converted to
>>> ->exec_op() ;-).
>> I have completely adapted to ->exec_op() hook up to replace the legacy
>> call-back.
> I suspect porting what you've done to the xway driver shouldn't be too
> complicated.
Not ported from xway_nand.c driver , we have developed from the scratch 
to make it work on
Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely 
different and most of the registers won't match.
if we port then it would be ugly and also what are the problem may occur 
we do not know.

Regards
Vadivel

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 18:40:53 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> >>> we'll be happy to have one more of the existing driver converted to  
> >>> ->exec_op() ;-).  
> >> I have completely adapted to ->exec_op() hook up to replace the legacy
> >> call-back.  
> > I suspect porting what you've done to the xway driver shouldn't be too
> > complicated.  
> Not ported from xway_nand.c driver , we have developed from the scratch 
> to make it work on
> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely 
> different and most of the registers won't match.
> if we port then it would be ugly and also what are the problem may occur 
> we do not know.

Sorry but IMO they look similar enough to try to merge them.

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 18:40:53 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> >>> we'll be happy to have one more of the existing driver converted to  
> >>> ->exec_op() ;-).  
> >> I have completely adapted to ->exec_op() hook up to replace the legacy
> >> call-back.  
> > I suspect porting what you've done to the xway driver shouldn't be too
> > complicated.  
> Not ported from xway_nand.c driver , we have developed from the scratch 
> to make it work on
> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely 
> different and most of the registers won't match.
> if we port then it would be ugly and also what are the problem may occur 
> we do not know.

Sorry but IMO they look similar enough to try to merge them.

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Andy Shevchenko]

On Thu, Apr 16, 2020 at 01:17:25PM +0200, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 18:40:53 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> 
> > >>> we'll be happy to have one more of the existing driver converted to  
> > >>> ->exec_op() ;-).  
> > >> I have completely adapted to ->exec_op() hook up to replace the legacy
> > >> call-back.  
> > > I suspect porting what you've done to the xway driver shouldn't be too
> > > complicated.  
> > Not ported from xway_nand.c driver , we have developed from the scratch 
> > to make it work on
> > Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely 
> > different and most of the registers won't match.
> > if we port then it would be ugly and also what are the problem may occur 
> > we do not know.
> 
> Sorry but IMO they look similar enough to try to merge them.

I agree. I tried to convince them internally... but here we are.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Andy Shevchenko]

On Thu, Apr 16, 2020 at 01:17:25PM +0200, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 18:40:53 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> 
> > >>> we'll be happy to have one more of the existing driver converted to  
> > >>> ->exec_op() ;-).  
> > >> I have completely adapted to ->exec_op() hook up to replace the legacy
> > >> call-back.  
> > > I suspect porting what you've done to the xway driver shouldn't be too
> > > complicated.  
> > Not ported from xway_nand.c driver , we have developed from the scratch 
> > to make it work on
> > Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely 
> > different and most of the registers won't match.
> > if we port then it would be ugly and also what are the problem may occur 
> > we do not know.
> 
> Sorry but IMO they look similar enough to try to merge them.

I agree. I tried to convince them internally... but here we are.

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Andy,

On 16/4/2020 7:32 pm, Andy Shevchenko wrote:
> On Thu, Apr 16, 2020 at 01:17:25PM +0200, Boris Brezillon wrote:
>> On Thu, 16 Apr 2020 18:40:53 +0800
>> "Ramuthevar, Vadivel MuruganX"
>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>
>>>>>> we'll be happy to have one more of the existing driver converted to
>>>>>> ->exec_op() ;-).
>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
>>>>> call-back.
>>>> I suspect porting what you've done to the xway driver shouldn't be too
>>>> complicated.
>>> Not ported from xway_nand.c driver , we have developed from the scratch
>>> to make it work on
>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
>>> different and most of the registers won't match.
>>> if we port then it would be ugly and also what are the problem may occur
>>> we do not know.
>> Sorry but IMO they look similar enough to try to merge them.
> I agree. I tried to convince them internally... but here we are.

Agreed,  will do the changes as Boris and Martin suggested, Thanks!

Regards
Vadivel

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Andy,

On 16/4/2020 7:32 pm, Andy Shevchenko wrote:
> On Thu, Apr 16, 2020 at 01:17:25PM +0200, Boris Brezillon wrote:
>> On Thu, 16 Apr 2020 18:40:53 +0800
>> "Ramuthevar, Vadivel MuruganX"
>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>
>>>>>> we'll be happy to have one more of the existing driver converted to
>>>>>> ->exec_op() ;-).
>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
>>>>> call-back.
>>>> I suspect porting what you've done to the xway driver shouldn't be too
>>>> complicated.
>>> Not ported from xway_nand.c driver , we have developed from the scratch
>>> to make it work on
>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
>>> different and most of the registers won't match.
>>> if we port then it would be ugly and also what are the problem may occur
>>> we do not know.
>> Sorry but IMO they look similar enough to try to merge them.
> I agree. I tried to convince them internally... but here we are.

Agreed,  will do the changes as Boris and Martin suggested, Thanks!

Regards
Vadivel

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 19:38:03 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> On 16/4/2020 7:17 pm, Boris Brezillon wrote:
> > On Thu, 16 Apr 2020 18:40:53 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> >  
> >>>>> we'll be happy to have one more of the existing driver converted to  
> >>>>> ->exec_op() ;-).  
> >>>> I have completely adapted to ->exec_op() hook up to replace the legacy
> >>>> call-back.  
> >>> I suspect porting what you've done to the xway driver shouldn't be too
> >>> complicated.  
> >> Not ported from xway_nand.c driver , we have developed from the scratch
> >> to make it work on
> >> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
> >> different and most of the registers won't match.
> >> if we port then it would be ugly and also what are the problem may occur
> >> we do not know.  
> > Sorry but IMO they look similar enough to try to merge them.  
> 
> Thanks! Boris, need suggestion from you since you are maintainer and 
> also expertise on mtd-subsystem.

I *was* the maintainer :).

> 
> There are different features involved and lines of code is more, if we 
> add new driver patches over xway-nand driver

How about retro-fitting the xway logic into your driver then? I mean,
adding a 100 lines of code to your driver to get rid of the 500+ lines
we have in xway_nand.c is still a win.

> 
> is completely looks ugly and it may disturb the existing functionality 
> as well since we don't have platform to validate:'(.

How ugly? Can you show us? Maybe we can come with a solution to make it
less ugly.

As for the testing part, there are 4 scenarios:

1/ Your changes work perfectly fine on older platforms. Yay \o/!
2/ You break the xway driver and existing users notice it before this
   series gets merged. Now you found someone to validate your changes.
3/ You break the xway driver and none of the existing users notice it
   before the driver is merged, but they notice it afterwards. Too bad
   this happened after we've merged the driver, but now you've found
   someone to help you fix the problem :P.
4/ You break things for old platforms but no one ever complains about
   it, either because there's no users left or because they never
   update their kernels. In any case, that's no longer your problem.
   Someone will remove those old platforms one day and get rid of the
   unneeded code in the NAND driver.

What's more likely to happen is #3 or #4, and I think the NAND
maintainer would be fine with both.

Note that the NAND subsystem is full of unmaintained legacy drivers, so
every time we see someone who could help us get rid or update one of
them we have to take this opportunity.

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 19:38:03 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> On 16/4/2020 7:17 pm, Boris Brezillon wrote:
> > On Thu, 16 Apr 2020 18:40:53 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> >  
> >>>>> we'll be happy to have one more of the existing driver converted to  
> >>>>> ->exec_op() ;-).  
> >>>> I have completely adapted to ->exec_op() hook up to replace the legacy
> >>>> call-back.  
> >>> I suspect porting what you've done to the xway driver shouldn't be too
> >>> complicated.  
> >> Not ported from xway_nand.c driver , we have developed from the scratch
> >> to make it work on
> >> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
> >> different and most of the registers won't match.
> >> if we port then it would be ugly and also what are the problem may occur
> >> we do not know.  
> > Sorry but IMO they look similar enough to try to merge them.  
> 
> Thanks! Boris, need suggestion from you since you are maintainer and 
> also expertise on mtd-subsystem.

I *was* the maintainer :).

> 
> There are different features involved and lines of code is more, if we 
> add new driver patches over xway-nand driver

How about retro-fitting the xway logic into your driver then? I mean,
adding a 100 lines of code to your driver to get rid of the 500+ lines
we have in xway_nand.c is still a win.

> 
> is completely looks ugly and it may disturb the existing functionality 
> as well since we don't have platform to validate:'(.

How ugly? Can you show us? Maybe we can come with a solution to make it
less ugly.

As for the testing part, there are 4 scenarios:

1/ Your changes work perfectly fine on older platforms. Yay \o/!
2/ You break the xway driver and existing users notice it before this
   series gets merged. Now you found someone to validate your changes.
3/ You break the xway driver and none of the existing users notice it
   before the driver is merged, but they notice it afterwards. Too bad
   this happened after we've merged the driver, but now you've found
   someone to help you fix the problem :P.
4/ You break things for old platforms but no one ever complains about
   it, either because there's no users left or because they never
   update their kernels. In any case, that's no longer your problem.
   Someone will remove those old platforms one day and get rid of the
   unneeded code in the NAND driver.

What's more likely to happen is #3 or #4, and I think the NAND
maintainer would be fine with both.

Note that the NAND subsystem is full of unmaintained legacy drivers, so
every time we see someone who could help us get rid or update one of
them we have to take this opportunity.

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Andy Shevchenko]

On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
> On Thu, 16 Apr 2020 19:38:03 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> > On 16/4/2020 7:17 pm, Boris Brezillon wrote:
> > > On Thu, 16 Apr 2020 18:40:53 +0800
> > > "Ramuthevar, Vadivel MuruganX"
> > > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

...

> > There are different features involved and lines of code is more, if we
> > add new driver patches over xway-nand driver
>
> How about retro-fitting the xway logic into your driver then? I mean,
> adding a 100 lines of code to your driver to get rid of the 500+ lines
> we have in xway_nand.c is still a win.
>
> >
> > is completely looks ugly and it may disturb the existing functionality
> > as well since we don't have platform to validate:'(.
>
> How ugly? Can you show us? Maybe we can come with a solution to make it
> less ugly.
>
> As for the testing part, there are 4 scenarios:
>
> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> 2/ You break the xway driver and existing users notice it before this
>    series gets merged. Now you found someone to validate your changes.
> 3/ You break the xway driver and none of the existing users notice it
>    before the driver is merged, but they notice it afterwards. Too bad
>    this happened after we've merged the driver, but now you've found
>    someone to help you fix the problem :P.
> 4/ You break things for old platforms but no one ever complains about
>    it, either because there's no users left or because they never
>    update their kernels. In any case, that's no longer your problem.
>    Someone will remove those old platforms one day and get rid of the
>    unneeded code in the NAND driver.
>
> What's more likely to happen is #3 or #4, and I think the NAND
> maintainer would be fine with both.
>
> Note that the NAND subsystem is full of unmaintained legacy drivers, so
> every time we see someone who could help us get rid or update one of
> them we have to take this opportunity.

Don't we rather insist to have a MAINTAINERS record for new code to
avoid (or delay at least) the fate of the legacy drivers?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Andy Shevchenko]

On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
> On Thu, 16 Apr 2020 19:38:03 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> > On 16/4/2020 7:17 pm, Boris Brezillon wrote:
> > > On Thu, 16 Apr 2020 18:40:53 +0800
> > > "Ramuthevar, Vadivel MuruganX"
> > > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

...

> > There are different features involved and lines of code is more, if we
> > add new driver patches over xway-nand driver
>
> How about retro-fitting the xway logic into your driver then? I mean,
> adding a 100 lines of code to your driver to get rid of the 500+ lines
> we have in xway_nand.c is still a win.
>
> >
> > is completely looks ugly and it may disturb the existing functionality
> > as well since we don't have platform to validate:'(.
>
> How ugly? Can you show us? Maybe we can come with a solution to make it
> less ugly.
>
> As for the testing part, there are 4 scenarios:
>
> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> 2/ You break the xway driver and existing users notice it before this
>    series gets merged. Now you found someone to validate your changes.
> 3/ You break the xway driver and none of the existing users notice it
>    before the driver is merged, but they notice it afterwards. Too bad
>    this happened after we've merged the driver, but now you've found
>    someone to help you fix the problem :P.
> 4/ You break things for old platforms but no one ever complains about
>    it, either because there's no users left or because they never
>    update their kernels. In any case, that's no longer your problem.
>    Someone will remove those old platforms one day and get rid of the
>    unneeded code in the NAND driver.
>
> What's more likely to happen is #3 or #4, and I think the NAND
> maintainer would be fine with both.
>
> Note that the NAND subsystem is full of unmaintained legacy drivers, so
> every time we see someone who could help us get rid or update one of
> them we have to take this opportunity.

Don't we rather insist to have a MAINTAINERS record for new code to
avoid (or delay at least) the fate of the legacy drivers?

-- 
With Best Regards,
Andy Shevchenko

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 15:26:51 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
> > On Thu, 16 Apr 2020 19:38:03 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:  
> > > On 16/4/2020 7:17 pm, Boris Brezillon wrote:  
> > > > On Thu, 16 Apr 2020 18:40:53 +0800
> > > > "Ramuthevar, Vadivel MuruganX"
> > > > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:  
> 
> ...
> 
> > > There are different features involved and lines of code is more, if we
> > > add new driver patches over xway-nand driver  
> >
> > How about retro-fitting the xway logic into your driver then? I mean,
> > adding a 100 lines of code to your driver to get rid of the 500+ lines
> > we have in xway_nand.c is still a win.
> >  
> > >
> > > is completely looks ugly and it may disturb the existing functionality
> > > as well since we don't have platform to validate:'(.  
> >
> > How ugly? Can you show us? Maybe we can come with a solution to make it
> > less ugly.
> >
> > As for the testing part, there are 4 scenarios:
> >
> > 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> > 2/ You break the xway driver and existing users notice it before this
> >    series gets merged. Now you found someone to validate your changes.
> > 3/ You break the xway driver and none of the existing users notice it
> >    before the driver is merged, but they notice it afterwards. Too bad
> >    this happened after we've merged the driver, but now you've found
> >    someone to help you fix the problem :P.
> > 4/ You break things for old platforms but no one ever complains about
> >    it, either because there's no users left or because they never
> >    update their kernels. In any case, that's no longer your problem.
> >    Someone will remove those old platforms one day and get rid of the
> >    unneeded code in the NAND driver.
> >
> > What's more likely to happen is #3 or #4, and I think the NAND
> > maintainer would be fine with both.
> >
> > Note that the NAND subsystem is full of unmaintained legacy drivers, so
> > every time we see someone who could help us get rid or update one of
> > them we have to take this opportunity.  
> 
> Don't we rather insist to have a MAINTAINERS record for new code to
> avoid (or delay at least) the fate of the legacy drivers?
> 

Well, that's what we do for new drivers, but the xway driver has been
added in 2012 and the policy was not enforced at that time. BTW, that
goes for most of the legacy drivers in have in the NAND subsystems
(some of them even predate the git era).

To be clear, I just checked and there's no official maintainer for this
driver. Best option would be to Cc the original author and contributors
who proposed functional changes to the code, as well as the MIPS
maintainers (Xway is a MIPS platform).

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Thu, 16 Apr 2020 15:26:51 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
> > On Thu, 16 Apr 2020 19:38:03 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:  
> > > On 16/4/2020 7:17 pm, Boris Brezillon wrote:  
> > > > On Thu, 16 Apr 2020 18:40:53 +0800
> > > > "Ramuthevar, Vadivel MuruganX"
> > > > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:  
> 
> ...
> 
> > > There are different features involved and lines of code is more, if we
> > > add new driver patches over xway-nand driver  
> >
> > How about retro-fitting the xway logic into your driver then? I mean,
> > adding a 100 lines of code to your driver to get rid of the 500+ lines
> > we have in xway_nand.c is still a win.
> >  
> > >
> > > is completely looks ugly and it may disturb the existing functionality
> > > as well since we don't have platform to validate:'(.  
> >
> > How ugly? Can you show us? Maybe we can come with a solution to make it
> > less ugly.
> >
> > As for the testing part, there are 4 scenarios:
> >
> > 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> > 2/ You break the xway driver and existing users notice it before this
> >    series gets merged. Now you found someone to validate your changes.
> > 3/ You break the xway driver and none of the existing users notice it
> >    before the driver is merged, but they notice it afterwards. Too bad
> >    this happened after we've merged the driver, but now you've found
> >    someone to help you fix the problem :P.
> > 4/ You break things for old platforms but no one ever complains about
> >    it, either because there's no users left or because they never
> >    update their kernels. In any case, that's no longer your problem.
> >    Someone will remove those old platforms one day and get rid of the
> >    unneeded code in the NAND driver.
> >
> > What's more likely to happen is #3 or #4, and I think the NAND
> > maintainer would be fine with both.
> >
> > Note that the NAND subsystem is full of unmaintained legacy drivers, so
> > every time we see someone who could help us get rid or update one of
> > them we have to take this opportunity.  
> 
> Don't we rather insist to have a MAINTAINERS record for new code to
> avoid (or delay at least) the fate of the legacy drivers?
> 

Well, that's what we do for new drivers, but the xway driver has been
added in 2012 and the policy was not enforced at that time. BTW, that
goes for most of the legacy drivers in have in the NAND subsystems
(some of them even predate the git era).

To be clear, I just checked and there's no official maintainer for this
driver. Best option would be to Cc the original author and contributors
who proposed functional changes to the code, as well as the MIPS
maintainers (Xway is a MIPS platform).

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Arnd Bergmann]

On Thu, Apr 16, 2020 at 2:40 PM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
> On Thu, 16 Apr 2020 15:26:51 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
> > <boris.brezillon@collabora.com> wrote:
> > > On Thu, 16 Apr 2020 19:38:03 +0800
> > > Note that the NAND subsystem is full of unmaintained legacy drivers, so
> > > every time we see someone who could help us get rid or update one of
> > > them we have to take this opportunity.
> >
> > Don't we rather insist to have a MAINTAINERS record for new code to
> > avoid (or delay at least) the fate of the legacy drivers?
> >
>
> Well, that's what we do for new drivers, but the xway driver has been
> added in 2012 and the policy was not enforced at that time. BTW, that
> goes for most of the legacy drivers in have in the NAND subsystems
> (some of them even predate the git era).
>
> To be clear, I just checked and there's no official maintainer for this
> driver. Best option would be to Cc the original author and contributors
> who proposed functional changes to the code, as well as the MIPS
> maintainers (Xway is a MIPS platform).

A lot of the pre-acquisition code for lantiq was contributed by Hauke
Mehrtens and John Crispin. There was an intermediate generation of
MIPS SoCs with patches posted for review  by Intel in 2018 (presumably
by the same organizatiob), but those were never resubmitted after v2
and never merged:

https://lore.kernel.org/linux-mips/20180803030237.3366-1-songjun.wu@linux.intel.com/

        Arnd

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Arnd Bergmann]

On Thu, Apr 16, 2020 at 2:40 PM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
> On Thu, 16 Apr 2020 15:26:51 +0300
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
> > <boris.brezillon@collabora.com> wrote:
> > > On Thu, 16 Apr 2020 19:38:03 +0800
> > > Note that the NAND subsystem is full of unmaintained legacy drivers, so
> > > every time we see someone who could help us get rid or update one of
> > > them we have to take this opportunity.
> >
> > Don't we rather insist to have a MAINTAINERS record for new code to
> > avoid (or delay at least) the fate of the legacy drivers?
> >
>
> Well, that's what we do for new drivers, but the xway driver has been
> added in 2012 and the policy was not enforced at that time. BTW, that
> goes for most of the legacy drivers in have in the NAND subsystems
> (some of them even predate the git era).
>
> To be clear, I just checked and there's no official maintainer for this
> driver. Best option would be to Cc the original author and contributors
> who proposed functional changes to the code, as well as the MIPS
> maintainers (Xway is a MIPS platform).

A lot of the pre-acquisition code for lantiq was contributed by Hauke
Mehrtens and John Crispin. There was an intermediate generation of
MIPS SoCs with patches posted for review  by Intel in 2018 (presumably
by the same organizatiob), but those were never resubmitted after v2
and never merged:

https://lore.kernel.org/linux-mips/20180803030237.3366-1-songjun.wu@linux.intel.com/

        Arnd

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[John Crispin]

On 16.04.20 15:20, Arnd Bergmann wrote:
> On Thu, Apr 16, 2020 at 2:40 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
>> On Thu, 16 Apr 2020 15:26:51 +0300
>> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
>>> <boris.brezillon@collabora.com> wrote:
>>>> On Thu, 16 Apr 2020 19:38:03 +0800
>>>> Note that the NAND subsystem is full of unmaintained legacy drivers, so
>>>> every time we see someone who could help us get rid or update one of
>>>> them we have to take this opportunity.
>>>
>>> Don't we rather insist to have a MAINTAINERS record for new code to
>>> avoid (or delay at least) the fate of the legacy drivers?
>>>
>>
>> Well, that's what we do for new drivers, but the xway driver has been
>> added in 2012 and the policy was not enforced at that time. BTW, that
>> goes for most of the legacy drivers in have in the NAND subsystems
>> (some of them even predate the git era).
>>
>> To be clear, I just checked and there's no official maintainer for this
>> driver. Best option would be to Cc the original author and contributors
>> who proposed functional changes to the code, as well as the MIPS
>> maintainers (Xway is a MIPS platform).
> 
> A lot of the pre-acquisition code for lantiq was contributed by Hauke
> Mehrtens and John Crispin. There was an intermediate generation of
> MIPS SoCs with patches posted for review  by Intel in 2018 (presumably
> by the same organizatiob), but those were never resubmitted after v2
> and never merged:
> 
> https://lore.kernel.org/linux-mips/20180803030237.3366-1-songjun.wu@linux.intel.com/
> 
>          Arnd
> 

Hi,

the legacy Mips SoC had a External Bus Unit (EBU), similar to an 
Intel/Hitachi style bus. It was used back then for lots of things, 
sometimes driving Leds via 74* latches, Arcadyan used it for external 
reset lines and very rarely was it used for nand.

Looking at this series and comparing it with xway_nand.c we see that the 
init sequence is near identical. Best guess is that the mountain lion 
uses an internal block very similar to what the legacy mips silicon used 
just in a newer generation and the new proposed driver is more feature 
complete.

If this is the case ideally the xway_nand.c is dropped and that silicon 
is made working with the newer driver. Chances are that we just need to 
add a "support less features" style flag.

Unfortunately i no longer have the evalkit for the Mips SoCs.

    John

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[John Crispin]

On 16.04.20 15:20, Arnd Bergmann wrote:
> On Thu, Apr 16, 2020 at 2:40 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
>> On Thu, 16 Apr 2020 15:26:51 +0300
>> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
>>> <boris.brezillon@collabora.com> wrote:
>>>> On Thu, 16 Apr 2020 19:38:03 +0800
>>>> Note that the NAND subsystem is full of unmaintained legacy drivers, so
>>>> every time we see someone who could help us get rid or update one of
>>>> them we have to take this opportunity.
>>>
>>> Don't we rather insist to have a MAINTAINERS record for new code to
>>> avoid (or delay at least) the fate of the legacy drivers?
>>>
>>
>> Well, that's what we do for new drivers, but the xway driver has been
>> added in 2012 and the policy was not enforced at that time. BTW, that
>> goes for most of the legacy drivers in have in the NAND subsystems
>> (some of them even predate the git era).
>>
>> To be clear, I just checked and there's no official maintainer for this
>> driver. Best option would be to Cc the original author and contributors
>> who proposed functional changes to the code, as well as the MIPS
>> maintainers (Xway is a MIPS platform).
> 
> A lot of the pre-acquisition code for lantiq was contributed by Hauke
> Mehrtens and John Crispin. There was an intermediate generation of
> MIPS SoCs with patches posted for review  by Intel in 2018 (presumably
> by the same organizatiob), but those were never resubmitted after v2
> and never merged:
> 
> https://lore.kernel.org/linux-mips/20180803030237.3366-1-songjun.wu@linux.intel.com/
> 
>          Arnd
> 

Hi,

the legacy Mips SoC had a External Bus Unit (EBU), similar to an 
Intel/Hitachi style bus. It was used back then for lots of things, 
sometimes driving Leds via 74* latches, Arcadyan used it for external 
reset lines and very rarely was it used for nand.

Looking at this series and comparing it with xway_nand.c we see that the 
init sequence is near identical. Best guess is that the mountain lion 
uses an internal block very similar to what the legacy mips silicon used 
just in a newer generation and the new proposed driver is more feature 
complete.

If this is the case ideally the xway_nand.c is dropped and that silicon 
is made working with the newer driver. Chances are that we just need to 
add a "support less features" style flag.

Unfortunately i no longer have the evalkit for the Mips SoCs.

    John

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Arnd,

On 16/4/2020 9:20 pm, Arnd Bergmann wrote:
> On Thu, Apr 16, 2020 at 2:40 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
>> On Thu, 16 Apr 2020 15:26:51 +0300
>> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
>>> <boris.brezillon@collabora.com> wrote:
>>>> On Thu, 16 Apr 2020 19:38:03 +0800
>>>> Note that the NAND subsystem is full of unmaintained legacy drivers, so
>>>> every time we see someone who could help us get rid or update one of
>>>> them we have to take this opportunity.
>>> Don't we rather insist to have a MAINTAINERS record for new code to
>>> avoid (or delay at least) the fate of the legacy drivers?
>>>
>> Well, that's what we do for new drivers, but the xway driver has been
>> added in 2012 and the policy was not enforced at that time. BTW, that
>> goes for most of the legacy drivers in have in the NAND subsystems
>> (some of them even predate the git era).
>>
>> To be clear, I just checked and there's no official maintainer for this
>> driver. Best option would be to Cc the original author and contributors
>> who proposed functional changes to the code, as well as the MIPS
>> maintainers (Xway is a MIPS platform).
> A lot of the pre-acquisition code for lantiq was contributed by Hauke
> Mehrtens and John Crispin. There was an intermediate generation of
> MIPS SoCs with patches posted for review  by Intel in 2018 (presumably
> by the same organizatiob), but those were never resubmitted after v2
> and never merged:
>
> https://lore.kernel.org/linux-mips/20180803030237.3366-1-songjun.wu@linux.intel.com/
Thank you for reviewing our patches and your time...
The above patches for different SoC which is MIPS based, but whatever 
the patch is sent by me is Intel X86 ATOM based LGM SoC.

Regards
Vadivel
>
>          Arnd

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Arnd,

On 16/4/2020 9:20 pm, Arnd Bergmann wrote:
> On Thu, Apr 16, 2020 at 2:40 PM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
>> On Thu, 16 Apr 2020 15:26:51 +0300
>> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>>> On Thu, Apr 16, 2020 at 3:03 PM Boris Brezillon
>>> <boris.brezillon@collabora.com> wrote:
>>>> On Thu, 16 Apr 2020 19:38:03 +0800
>>>> Note that the NAND subsystem is full of unmaintained legacy drivers, so
>>>> every time we see someone who could help us get rid or update one of
>>>> them we have to take this opportunity.
>>> Don't we rather insist to have a MAINTAINERS record for new code to
>>> avoid (or delay at least) the fate of the legacy drivers?
>>>
>> Well, that's what we do for new drivers, but the xway driver has been
>> added in 2012 and the policy was not enforced at that time. BTW, that
>> goes for most of the legacy drivers in have in the NAND subsystems
>> (some of them even predate the git era).
>>
>> To be clear, I just checked and there's no official maintainer for this
>> driver. Best option would be to Cc the original author and contributors
>> who proposed functional changes to the code, as well as the MIPS
>> maintainers (Xway is a MIPS platform).
> A lot of the pre-acquisition code for lantiq was contributed by Hauke
> Mehrtens and John Crispin. There was an intermediate generation of
> MIPS SoCs with patches posted for review  by Intel in 2018 (presumably
> by the same organizatiob), but those were never resubmitted after v2
> and never merged:
>
> https://lore.kernel.org/linux-mips/20180803030237.3366-1-songjun.wu@linux.intel.com/
Thank you for reviewing our patches and your time...
The above patches for different SoC which is MIPS based, but whatever 
the patch is sent by me is Intel X86 ATOM based LGM SoC.

Regards
Vadivel
>
>          Arnd

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Martin Blumenstingl]

Hi Vadivel, Hi Boris,

On Thu, Apr 16, 2020 at 1:57 PM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
[...]
> As for the testing part, there are 4 scenarios:
>
> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
this would be awesome \o/

> 2/ You break the xway driver and existing users notice it before this
>    series gets merged. Now you found someone to validate your changes.
The xway_nand driver is still used by 9 (or so) boards in OpenWrt: one
Danube, one ARX100 and the other 7 with VRX200
I can be the person to find out whether your changes break one of
these boards with VRX200 SoC and 128MB SLC NAND (and software ECC
since AFAIK this SoC doesn't have a hardware ECC engine).


Best regards,
Martin

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Martin Blumenstingl]

Hi Vadivel, Hi Boris,

On Thu, Apr 16, 2020 at 1:57 PM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
[...]
> As for the testing part, there are 4 scenarios:
>
> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
this would be awesome \o/

> 2/ You break the xway driver and existing users notice it before this
>    series gets merged. Now you found someone to validate your changes.
The xway_nand driver is still used by 9 (or so) boards in OpenWrt: one
Danube, one ARX100 and the other 7 with VRX200
I can be the person to find out whether your changes break one of
these boards with VRX200 SoC and 128MB SLC NAND (and software ECC
since AFAIK this SoC doesn't have a hardware ECC engine).


Best regards,
Martin

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

On 16/4/2020 7:57 pm, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 19:38:03 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> On 16/4/2020 7:17 pm, Boris Brezillon wrote:
>>> On Thu, 16 Apr 2020 18:40:53 +0800
>>> "Ramuthevar, Vadivel MuruganX"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>   
>>>>>>> we'll be happy to have one more of the existing driver converted to
>>>>>>> ->exec_op() ;-).
>>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
>>>>>> call-back.
>>>>> I suspect porting what you've done to the xway driver shouldn't be too
>>>>> complicated.
>>>> Not ported from xway_nand.c driver , we have developed from the scratch
>>>> to make it work on
>>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
>>>> different and most of the registers won't match.
>>>> if we port then it would be ugly and also what are the problem may occur
>>>> we do not know.
>>> Sorry but IMO they look similar enough to try to merge them.
>> Thanks! Boris, need suggestion from you since you are maintainer and
>> also expertise on mtd-subsystem.
> I *was* the maintainer :).
>
>> There are different features involved and lines of code is more, if we
>> add new driver patches over xway-nand driver
> How about retro-fitting the xway logic into your driver then? I mean,
> adding a 100 lines of code to your driver to get rid of the 500+ lines
> we have in xway_nand.c is still a win.
>
>> is completely looks ugly and it may disturb the existing functionality
>> as well since we don't have platform to validate:'(.
> How ugly? Can you show us? Maybe we can come with a solution to make it
> less ugly.
>
> As for the testing part, there are 4 scenarios:
>
> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> 2/ You break the xway driver and existing users notice it before this
>     series gets merged. Now you found someone to validate your changes.
> 3/ You break the xway driver and none of the existing users notice it
>     before the driver is merged, but they notice it afterwards. Too bad
>     this happened after we've merged the driver, but now you've found
>     someone to help you fix the problem :P.
> 4/ You break things for old platforms but no one ever complains about
>     it, either because there's no users left or because they never
>     update their kernels. In any case, that's no longer your problem.
>     Someone will remove those old platforms one day and get rid of the
>     unneeded code in the NAND driver.
>
> What's more likely to happen is #3 or #4, and I think the NAND
> maintainer would be fine with both.
>
> Note that the NAND subsystem is full of unmaintained legacy drivers, so
> every time we see someone who could help us get rid or update one of
> them we have to take this opportunity.
Agreed!, Thank you very much for the suggestions and clear inputs.
To proceed further, can you please share your inputs to dividing the tasks
and patches to be sent if possible.

Regards
Vadivel

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

On 16/4/2020 7:57 pm, Boris Brezillon wrote:
> On Thu, 16 Apr 2020 19:38:03 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> On 16/4/2020 7:17 pm, Boris Brezillon wrote:
>>> On Thu, 16 Apr 2020 18:40:53 +0800
>>> "Ramuthevar, Vadivel MuruganX"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>   
>>>>>>> we'll be happy to have one more of the existing driver converted to
>>>>>>> ->exec_op() ;-).
>>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
>>>>>> call-back.
>>>>> I suspect porting what you've done to the xway driver shouldn't be too
>>>>> complicated.
>>>> Not ported from xway_nand.c driver , we have developed from the scratch
>>>> to make it work on
>>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
>>>> different and most of the registers won't match.
>>>> if we port then it would be ugly and also what are the problem may occur
>>>> we do not know.
>>> Sorry but IMO they look similar enough to try to merge them.
>> Thanks! Boris, need suggestion from you since you are maintainer and
>> also expertise on mtd-subsystem.
> I *was* the maintainer :).
>
>> There are different features involved and lines of code is more, if we
>> add new driver patches over xway-nand driver
> How about retro-fitting the xway logic into your driver then? I mean,
> adding a 100 lines of code to your driver to get rid of the 500+ lines
> we have in xway_nand.c is still a win.
>
>> is completely looks ugly and it may disturb the existing functionality
>> as well since we don't have platform to validate:'(.
> How ugly? Can you show us? Maybe we can come with a solution to make it
> less ugly.
>
> As for the testing part, there are 4 scenarios:
>
> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> 2/ You break the xway driver and existing users notice it before this
>     series gets merged. Now you found someone to validate your changes.
> 3/ You break the xway driver and none of the existing users notice it
>     before the driver is merged, but they notice it afterwards. Too bad
>     this happened after we've merged the driver, but now you've found
>     someone to help you fix the problem :P.
> 4/ You break things for old platforms but no one ever complains about
>     it, either because there's no users left or because they never
>     update their kernels. In any case, that's no longer your problem.
>     Someone will remove those old platforms one day and get rid of the
>     unneeded code in the NAND driver.
>
> What's more likely to happen is #3 or #4, and I think the NAND
> maintainer would be fine with both.
>
> Note that the NAND subsystem is full of unmaintained legacy drivers, so
> every time we see someone who could help us get rid or update one of
> them we have to take this opportunity.
Agreed!, Thank you very much for the suggestions and clear inputs.
To proceed further, can you please share your inputs to dividing the tasks
and patches to be sent if possible.

Regards
Vadivel

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Fri, 17 Apr 2020 13:21:39 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> Hi Boris,
> 
> On 16/4/2020 7:57 pm, Boris Brezillon wrote:
> > On Thu, 16 Apr 2020 19:38:03 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> >  
> >> On 16/4/2020 7:17 pm, Boris Brezillon wrote:  
> >>> On Thu, 16 Apr 2020 18:40:53 +0800
> >>> "Ramuthevar, Vadivel MuruganX"
> >>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> >>>     
> >>>>>>> we'll be happy to have one more of the existing driver converted to  
> >>>>>>> ->exec_op() ;-).  
> >>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
> >>>>>> call-back.  
> >>>>> I suspect porting what you've done to the xway driver shouldn't be too
> >>>>> complicated.  
> >>>> Not ported from xway_nand.c driver , we have developed from the scratch
> >>>> to make it work on
> >>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
> >>>> different and most of the registers won't match.
> >>>> if we port then it would be ugly and also what are the problem may occur
> >>>> we do not know.  
> >>> Sorry but IMO they look similar enough to try to merge them.  
> >> Thanks! Boris, need suggestion from you since you are maintainer and
> >> also expertise on mtd-subsystem.  
> > I *was* the maintainer :).
> >  
> >> There are different features involved and lines of code is more, if we
> >> add new driver patches over xway-nand driver  
> > How about retro-fitting the xway logic into your driver then? I mean,
> > adding a 100 lines of code to your driver to get rid of the 500+ lines
> > we have in xway_nand.c is still a win.
> >  
> >> is completely looks ugly and it may disturb the existing functionality
> >> as well since we don't have platform to validate:'(.  
> > How ugly? Can you show us? Maybe we can come with a solution to make it
> > less ugly.
> >
> > As for the testing part, there are 4 scenarios:
> >
> > 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> > 2/ You break the xway driver and existing users notice it before this
> >     series gets merged. Now you found someone to validate your changes.
> > 3/ You break the xway driver and none of the existing users notice it
> >     before the driver is merged, but they notice it afterwards. Too bad
> >     this happened after we've merged the driver, but now you've found
> >     someone to help you fix the problem :P.
> > 4/ You break things for old platforms but no one ever complains about
> >     it, either because there's no users left or because they never
> >     update their kernels. In any case, that's no longer your problem.
> >     Someone will remove those old platforms one day and get rid of the
> >     unneeded code in the NAND driver.
> >
> > What's more likely to happen is #3 or #4, and I think the NAND
> > maintainer would be fine with both.
> >
> > Note that the NAND subsystem is full of unmaintained legacy drivers, so
> > every time we see someone who could help us get rid or update one of
> > them we have to take this opportunity.  
> Agreed!, Thank you very much for the suggestions and clear inputs.
> To proceed further, can you please share your inputs to dividing the tasks
> and patches to be sent if possible.

Let's start with the new version you were about to post. We'll see how
we can merge both drivers based on that.

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Boris Brezillon]

On Fri, 17 Apr 2020 13:21:39 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@linux.intel.com> wrote:

> Hi Boris,
> 
> On 16/4/2020 7:57 pm, Boris Brezillon wrote:
> > On Thu, 16 Apr 2020 19:38:03 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> >  
> >> On 16/4/2020 7:17 pm, Boris Brezillon wrote:  
> >>> On Thu, 16 Apr 2020 18:40:53 +0800
> >>> "Ramuthevar, Vadivel MuruganX"
> >>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
> >>>     
> >>>>>>> we'll be happy to have one more of the existing driver converted to  
> >>>>>>> ->exec_op() ;-).  
> >>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
> >>>>>> call-back.  
> >>>>> I suspect porting what you've done to the xway driver shouldn't be too
> >>>>> complicated.  
> >>>> Not ported from xway_nand.c driver , we have developed from the scratch
> >>>> to make it work on
> >>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
> >>>> different and most of the registers won't match.
> >>>> if we port then it would be ugly and also what are the problem may occur
> >>>> we do not know.  
> >>> Sorry but IMO they look similar enough to try to merge them.  
> >> Thanks! Boris, need suggestion from you since you are maintainer and
> >> also expertise on mtd-subsystem.  
> > I *was* the maintainer :).
> >  
> >> There are different features involved and lines of code is more, if we
> >> add new driver patches over xway-nand driver  
> > How about retro-fitting the xway logic into your driver then? I mean,
> > adding a 100 lines of code to your driver to get rid of the 500+ lines
> > we have in xway_nand.c is still a win.
> >  
> >> is completely looks ugly and it may disturb the existing functionality
> >> as well since we don't have platform to validate:'(.  
> > How ugly? Can you show us? Maybe we can come with a solution to make it
> > less ugly.
> >
> > As for the testing part, there are 4 scenarios:
> >
> > 1/ Your changes work perfectly fine on older platforms. Yay \o/!
> > 2/ You break the xway driver and existing users notice it before this
> >     series gets merged. Now you found someone to validate your changes.
> > 3/ You break the xway driver and none of the existing users notice it
> >     before the driver is merged, but they notice it afterwards. Too bad
> >     this happened after we've merged the driver, but now you've found
> >     someone to help you fix the problem :P.
> > 4/ You break things for old platforms but no one ever complains about
> >     it, either because there's no users left or because they never
> >     update their kernels. In any case, that's no longer your problem.
> >     Someone will remove those old platforms one day and get rid of the
> >     unneeded code in the NAND driver.
> >
> > What's more likely to happen is #3 or #4, and I think the NAND
> > maintainer would be fine with both.
> >
> > Note that the NAND subsystem is full of unmaintained legacy drivers, so
> > every time we see someone who could help us get rid or update one of
> > them we have to take this opportunity.  
> Agreed!, Thank you very much for the suggestions and clear inputs.
> To proceed further, can you please share your inputs to dividing the tasks
> and patches to be sent if possible.

Let's start with the new version you were about to post. We'll see how
we can merge both drivers based on that.

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

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

On 17/4/2020 3:02 pm, Boris Brezillon wrote:
> On Fri, 17 Apr 2020 13:21:39 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> Hi Boris,
>>
>> On 16/4/2020 7:57 pm, Boris Brezillon wrote:
>>> On Thu, 16 Apr 2020 19:38:03 +0800
>>> "Ramuthevar, Vadivel MuruganX"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>   
>>>> On 16/4/2020 7:17 pm, Boris Brezillon wrote:
>>>>> On Thu, 16 Apr 2020 18:40:53 +0800
>>>>> "Ramuthevar, Vadivel MuruganX"
>>>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>>>      
>>>>>>>>> we'll be happy to have one more of the existing driver converted to
>>>>>>>>> ->exec_op() ;-).
>>>>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
>>>>>>>> call-back.
>>>>>>> I suspect porting what you've done to the xway driver shouldn't be too
>>>>>>> complicated.
>>>>>> Not ported from xway_nand.c driver , we have developed from the scratch
>>>>>> to make it work on
>>>>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
>>>>>> different and most of the registers won't match.
>>>>>> if we port then it would be ugly and also what are the problem may occur
>>>>>> we do not know.
>>>>> Sorry but IMO they look similar enough to try to merge them.
>>>> Thanks! Boris, need suggestion from you since you are maintainer and
>>>> also expertise on mtd-subsystem.
>>> I *was* the maintainer :).
>>>   
>>>> There are different features involved and lines of code is more, if we
>>>> add new driver patches over xway-nand driver
>>> How about retro-fitting the xway logic into your driver then? I mean,
>>> adding a 100 lines of code to your driver to get rid of the 500+ lines
>>> we have in xway_nand.c is still a win.
>>>   
>>>> is completely looks ugly and it may disturb the existing functionality
>>>> as well since we don't have platform to validate:'(.
>>> How ugly? Can you show us? Maybe we can come with a solution to make it
>>> less ugly.
>>>
>>> As for the testing part, there are 4 scenarios:
>>>
>>> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
>>> 2/ You break the xway driver and existing users notice it before this
>>>      series gets merged. Now you found someone to validate your changes.
>>> 3/ You break the xway driver and none of the existing users notice it
>>>      before the driver is merged, but they notice it afterwards. Too bad
>>>      this happened after we've merged the driver, but now you've found
>>>      someone to help you fix the problem :P.
>>> 4/ You break things for old platforms but no one ever complains about
>>>      it, either because there's no users left or because they never
>>>      update their kernels. In any case, that's no longer your problem.
>>>      Someone will remove those old platforms one day and get rid of the
>>>      unneeded code in the NAND driver.
>>>
>>> What's more likely to happen is #3 or #4, and I think the NAND
>>> maintainer would be fine with both.
>>>
>>> Note that the NAND subsystem is full of unmaintained legacy drivers, so
>>> every time we see someone who could help us get rid or update one of
>>> them we have to take this opportunity.
>> Agreed!, Thank you very much for the suggestions and clear inputs.
>> To proceed further, can you please share your inputs to dividing the tasks
>> and patches to be sent if possible.
> Let's start with the new version you were about to post. We'll see how
> we can merge both drivers based on that.

Thank you very much for the review comments and inputs , will post the 
patches soon.

Regards
Vadivel

Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Boris,

On 17/4/2020 3:02 pm, Boris Brezillon wrote:
> On Fri, 17 Apr 2020 13:21:39 +0800
> "Ramuthevar, Vadivel MuruganX"
> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>
>> Hi Boris,
>>
>> On 16/4/2020 7:57 pm, Boris Brezillon wrote:
>>> On Thu, 16 Apr 2020 19:38:03 +0800
>>> "Ramuthevar, Vadivel MuruganX"
>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>   
>>>> On 16/4/2020 7:17 pm, Boris Brezillon wrote:
>>>>> On Thu, 16 Apr 2020 18:40:53 +0800
>>>>> "Ramuthevar, Vadivel MuruganX"
>>>>> <vadivel.muruganx.ramuthevar@linux.intel.com> wrote:
>>>>>      
>>>>>>>>> we'll be happy to have one more of the existing driver converted to
>>>>>>>>> ->exec_op() ;-).
>>>>>>>> I have completely adapted to ->exec_op() hook up to replace the legacy
>>>>>>>> call-back.
>>>>>>> I suspect porting what you've done to the xway driver shouldn't be too
>>>>>>> complicated.
>>>>>> Not ported from xway_nand.c driver , we have developed from the scratch
>>>>>> to make it work on
>>>>>> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
>>>>>> different and most of the registers won't match.
>>>>>> if we port then it would be ugly and also what are the problem may occur
>>>>>> we do not know.
>>>>> Sorry but IMO they look similar enough to try to merge them.
>>>> Thanks! Boris, need suggestion from you since you are maintainer and
>>>> also expertise on mtd-subsystem.
>>> I *was* the maintainer :).
>>>   
>>>> There are different features involved and lines of code is more, if we
>>>> add new driver patches over xway-nand driver
>>> How about retro-fitting the xway logic into your driver then? I mean,
>>> adding a 100 lines of code to your driver to get rid of the 500+ lines
>>> we have in xway_nand.c is still a win.
>>>   
>>>> is completely looks ugly and it may disturb the existing functionality
>>>> as well since we don't have platform to validate:'(.
>>> How ugly? Can you show us? Maybe we can come with a solution to make it
>>> less ugly.
>>>
>>> As for the testing part, there are 4 scenarios:
>>>
>>> 1/ Your changes work perfectly fine on older platforms. Yay \o/!
>>> 2/ You break the xway driver and existing users notice it before this
>>>      series gets merged. Now you found someone to validate your changes.
>>> 3/ You break the xway driver and none of the existing users notice it
>>>      before the driver is merged, but they notice it afterwards. Too bad
>>>      this happened after we've merged the driver, but now you've found
>>>      someone to help you fix the problem :P.
>>> 4/ You break things for old platforms but no one ever complains about
>>>      it, either because there's no users left or because they never
>>>      update their kernels. In any case, that's no longer your problem.
>>>      Someone will remove those old platforms one day and get rid of the
>>>      unneeded code in the NAND driver.
>>>
>>> What's more likely to happen is #3 or #4, and I think the NAND
>>> maintainer would be fine with both.
>>>
>>> Note that the NAND subsystem is full of unmaintained legacy drivers, so
>>> every time we see someone who could help us get rid or update one of
>>> them we have to take this opportunity.
>> Agreed!, Thank you very much for the suggestions and clear inputs.
>> To proceed further, can you please share your inputs to dividing the tasks
>> and patches to be sent if possible.
> Let's start with the new version you were about to post. We'll see how
> we can merge both drivers based on that.

Thank you very much for the review comments and inputs , will post the 
patches soon.

Regards
Vadivel

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