[PATCH v3 0/7] OMAP2+ OneNAND driver update

[PATCH v3 0/7] OMAP2+ OneNAND driver update

[Ladislav Michl]

Hi there,

this patch serie updates OMAP2+ OneNAND driver to the present times, making
it fully DT configurable.

Patches 2-6 are intended for 4.15 merge window via mtd-tree as they are
cleanups only.

Patches 1 and 7 are targetted for 4.16 merge window via mtd tree as it seems
nobody tested these changes (on Nokias most importantly) so far.

Please note that unlike previous driver version, which basically ignored
DT specified timings, this one relies on it, so it is important to get
it right in your DT (dumping it from previous kernel version).

In case synchronous timings is requested, it is okay to specify timings
for the slowest chip ever used for you board as it is evetually optimized
after chip probe.

Ladislav Michl (7):
  memory: omap-gpmc: Refactor OneNAND support
  mtd: onenand: omap2: Remove regulator support
  mtd: onenand: omap2: Remove skip initial unlocking support
  mtd: onenand: omap2: Remove partitioning support from platform data
  mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation
  mtd: onenand: omap2: Do not make delay for GPIO OMAP3 specific
  mtd: onenand: omap2: Configure driver from DT

 drivers/memory/omap-gpmc.c  | 158 ++++++++++----
 drivers/mtd/onenand/omap2.c | 512 ++++++++++++++++----------------------------
 include/linux/omap-gpmc.h   |  25 +++
 3 files changed, 330 insertions(+), 365 deletions(-)

-- 
2.11.0


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

[PATCH v3 0/7] OMAP2+ OneNAND driver update

[Ladislav Michl]

Hi there,

this patch serie updates OMAP2+ OneNAND driver to the present times, making
it fully DT configurable.

Patches 2-6 are intended for 4.15 merge window via mtd-tree as they are
cleanups only.

Patches 1 and 7 are targetted for 4.16 merge window via mtd tree as it seems
nobody tested these changes (on Nokias most importantly) so far.

Please note that unlike previous driver version, which basically ignored
DT specified timings, this one relies on it, so it is important to get
it right in your DT (dumping it from previous kernel version).

In case synchronous timings is requested, it is okay to specify timings
for the slowest chip ever used for you board as it is evetually optimized
after chip probe.

Ladislav Michl (7):
  memory: omap-gpmc: Refactor OneNAND support
  mtd: onenand: omap2: Remove regulator support
  mtd: onenand: omap2: Remove skip initial unlocking support
  mtd: onenand: omap2: Remove partitioning support from platform data
  mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation
  mtd: onenand: omap2: Do not make delay for GPIO OMAP3 specific
  mtd: onenand: omap2: Configure driver from DT

 drivers/memory/omap-gpmc.c  | 158 ++++++++++----
 drivers/mtd/onenand/omap2.c | 512 ++++++++++++++++----------------------------
 include/linux/omap-gpmc.h   |  25 +++
 3 files changed, 330 insertions(+), 365 deletions(-)

-- 
2.11.0

[PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

Use generic probe function to deal with OneNAND node and remove now useless
gpmc_probe_onenand_child function.
Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
and prepare for MTD driver DTfication.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: add gpmc_omap_onenand_set_timings description
 -v3: none

 drivers/memory/omap-gpmc.c | 158 +++++++++++++++++++++++++++++++++------------
 include/linux/omap-gpmc.h  |  25 +++++++
 2 files changed, 142 insertions(+), 41 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 0e30ee1c8677..90a66b3f7ae1 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -32,7 +32,6 @@
 #include <linux/pm_runtime.h>
 
 #include <linux/platform_data/mtd-nand-omap2.h>
-#include <linux/platform_data/mtd-onenand-omap2.h>
 
 #include <asm/mach-types.h>
 
@@ -1138,6 +1137,112 @@ struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *reg, int cs)
 }
 EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
 
+static void gpmc_omap_onenand_calc_sync_timings(struct gpmc_timings *t,
+						struct gpmc_settings *s,
+						int freq, int latency)
+{
+	struct gpmc_device_timings dev_t;
+	const int t_cer  = 15;
+	const int t_avdp = 12;
+	const int t_cez  = 20; /* max of t_cez, t_oez */
+	const int t_wpl  = 40;
+	const int t_wph  = 30;
+	int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
+
+	switch (freq) {
+	case 104:
+		min_gpmc_clk_period = 9600; /* 104 MHz */
+		t_ces   = 3;
+		t_avds  = 4;
+		t_avdh  = 2;
+		t_ach   = 3;
+		t_aavdh = 6;
+		t_rdyo  = 6;
+		break;
+	case 83:
+		min_gpmc_clk_period = 12000; /* 83 MHz */
+		t_ces   = 5;
+		t_avds  = 4;
+		t_avdh  = 2;
+		t_ach   = 6;
+		t_aavdh = 6;
+		t_rdyo  = 9;
+		break;
+	case 66:
+		min_gpmc_clk_period = 15000; /* 66 MHz */
+		t_ces   = 6;
+		t_avds  = 5;
+		t_avdh  = 2;
+		t_ach   = 6;
+		t_aavdh = 6;
+		t_rdyo  = 11;
+		break;
+	default:
+		min_gpmc_clk_period = 18500; /* 54 MHz */
+		t_ces   = 7;
+		t_avds  = 7;
+		t_avdh  = 7;
+		t_ach   = 9;
+		t_aavdh = 7;
+		t_rdyo  = 15;
+		break;
+	}
+
+	/* Set synchronous read timings */
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	if (!s->sync_write) {
+		dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
+		dev_t.t_wpl = t_wpl * 1000;
+		dev_t.t_wph = t_wph * 1000;
+		dev_t.t_aavdh = t_aavdh * 1000;
+	}
+	dev_t.ce_xdelay = true;
+	dev_t.avd_xdelay = true;
+	dev_t.oe_xdelay = true;
+	dev_t.we_xdelay = true;
+	dev_t.clk = min_gpmc_clk_period;
+	dev_t.t_bacc = dev_t.clk;
+	dev_t.t_ces = t_ces * 1000;
+	dev_t.t_avds = t_avds * 1000;
+	dev_t.t_avdh = t_avdh * 1000;
+	dev_t.t_ach = t_ach * 1000;
+	dev_t.cyc_iaa = (latency + 1);
+	dev_t.t_cez_r = t_cez * 1000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.cyc_aavdh_oe = 1;
+	dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
+
+	gpmc_calc_timings(t, s, &dev_t);
+}
+
+int gpmc_omap_onenand_set_timings(struct device *dev, int cs, int freq,
+				  int latency,
+				  struct gpmc_onenand_info *info)
+{
+	int ret;
+	struct gpmc_timings gpmc_t;
+	struct gpmc_settings gpmc_s;
+
+	gpmc_read_settings_dt(dev->of_node, &gpmc_s);
+
+	info->sync_read = gpmc_s.sync_read;
+	info->sync_write = gpmc_s.sync_write;
+	info->burst_len = gpmc_s.burst_len;
+
+	if (!gpmc_s.sync_read && !gpmc_s.sync_write)
+		return 0;
+
+	gpmc_omap_onenand_calc_sync_timings(&gpmc_t, &gpmc_s, freq, latency);
+
+	ret = gpmc_cs_program_settings(cs, &gpmc_s);
+	if (ret < 0)
+		return ret;
+
+	return gpmc_cs_set_timings(cs, &gpmc_t, &gpmc_s);
+}
+EXPORT_SYMBOL_GPL(gpmc_omap_onenand_set_timings);
+
 int gpmc_get_client_irq(unsigned irq_config)
 {
 	if (!gpmc_irq_domain) {
@@ -1916,41 +2021,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
 		of_property_read_bool(np, "gpmc,time-para-granularity");
 }
 
-#if IS_ENABLED(CONFIG_MTD_ONENAND)
-static int gpmc_probe_onenand_child(struct platform_device *pdev,
-				 struct device_node *child)
-{
-	u32 val;
-	struct omap_onenand_platform_data *gpmc_onenand_data;
-
-	if (of_property_read_u32(child, "reg", &val) < 0) {
-		dev_err(&pdev->dev, "%pOF has no 'reg' property\n",
-			child);
-		return -ENODEV;
-	}
-
-	gpmc_onenand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_onenand_data),
-					 GFP_KERNEL);
-	if (!gpmc_onenand_data)
-		return -ENOMEM;
-
-	gpmc_onenand_data->cs = val;
-	gpmc_onenand_data->of_node = child;
-	gpmc_onenand_data->dma_channel = -1;
-
-	if (!of_property_read_u32(child, "dma-channel", &val))
-		gpmc_onenand_data->dma_channel = val;
-
-	return gpmc_onenand_init(gpmc_onenand_data);
-}
-#else
-static int gpmc_probe_onenand_child(struct platform_device *pdev,
-				    struct device_node *child)
-{
-	return 0;
-}
-#endif
-
 /**
  * gpmc_probe_generic_child - configures the gpmc for a child device
  * @pdev:	pointer to gpmc platform device
@@ -2053,6 +2123,16 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
 		}
 	}
 
+	if (of_node_cmp(child->name, "onenand") == 0) {
+		/* Warn about older DT blobs with no compatible property */
+		if (!of_property_read_bool(child, "compatible")) {
+			dev_warn(&pdev->dev,
+				 "Incompatible OneNAND node: missing compatible");
+			ret = -EINVAL;
+			goto err;
+		}
+	}
+
 	if (of_device_is_compatible(child, "ti,omap2-nand")) {
 		/* NAND specific setup */
 		val = 8;
@@ -2189,11 +2269,7 @@ static void gpmc_probe_dt_children(struct platform_device *pdev)
 		if (!child->name)
 			continue;
 
-		if (of_node_cmp(child->name, "onenand") == 0)
-			ret = gpmc_probe_onenand_child(pdev, child);
-		else
-			ret = gpmc_probe_generic_child(pdev, child);
-
+		ret = gpmc_probe_generic_child(pdev, child);
 		if (ret) {
 			dev_err(&pdev->dev, "failed to probe DT child '%s': %d\n",
 				child->name, ret);
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index edfa280c3d56..067bea5e98c4 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -25,15 +25,40 @@ struct gpmc_nand_ops {
 
 struct gpmc_nand_regs;
 
+struct gpmc_onenand_info {
+	bool sync_read;
+	bool sync_write;
+	int burst_len;
+};
+
 #if IS_ENABLED(CONFIG_OMAP_GPMC)
 struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
 					     int cs);
+/**
+ * gpmc_omap_onenand_set_timings - set optimized sync timings.
+ * @cs:      Chip Select Region
+ * @freq:    Chip frequency
+ * @latency: Burst latency cycle count
+ * @info:    Structure describing parameters used
+ */
+int gpmc_omap_onenand_set_timings(struct device *dev, int cs, int freq,
+				  int latency,
+				  struct gpmc_onenand_info *info);
+
 #else
 static inline struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
 							   int cs)
 {
 	return NULL;
 }
+
+static inline
+int gpmc_omap_onenand_set_timings(struct device *dev, int cs, int freq,
+				  int latency,
+				  struct gpmc_onenand_info *info)
+{
+	return -EINVAL;
+}
 #endif /* CONFIG_OMAP_GPMC */
 
 extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
-- 
2.11.0


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

[PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

Use generic probe function to deal with OneNAND node and remove now useless
gpmc_probe_onenand_child function.
Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
and prepare for MTD driver DTfication.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: add gpmc_omap_onenand_set_timings description
 -v3: none

 drivers/memory/omap-gpmc.c | 158 +++++++++++++++++++++++++++++++++------------
 include/linux/omap-gpmc.h  |  25 +++++++
 2 files changed, 142 insertions(+), 41 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 0e30ee1c8677..90a66b3f7ae1 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -32,7 +32,6 @@
 #include <linux/pm_runtime.h>
 
 #include <linux/platform_data/mtd-nand-omap2.h>
-#include <linux/platform_data/mtd-onenand-omap2.h>
 
 #include <asm/mach-types.h>
 
@@ -1138,6 +1137,112 @@ struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *reg, int cs)
 }
 EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
 
+static void gpmc_omap_onenand_calc_sync_timings(struct gpmc_timings *t,
+						struct gpmc_settings *s,
+						int freq, int latency)
+{
+	struct gpmc_device_timings dev_t;
+	const int t_cer  = 15;
+	const int t_avdp = 12;
+	const int t_cez  = 20; /* max of t_cez, t_oez */
+	const int t_wpl  = 40;
+	const int t_wph  = 30;
+	int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
+
+	switch (freq) {
+	case 104:
+		min_gpmc_clk_period = 9600; /* 104 MHz */
+		t_ces   = 3;
+		t_avds  = 4;
+		t_avdh  = 2;
+		t_ach   = 3;
+		t_aavdh = 6;
+		t_rdyo  = 6;
+		break;
+	case 83:
+		min_gpmc_clk_period = 12000; /* 83 MHz */
+		t_ces   = 5;
+		t_avds  = 4;
+		t_avdh  = 2;
+		t_ach   = 6;
+		t_aavdh = 6;
+		t_rdyo  = 9;
+		break;
+	case 66:
+		min_gpmc_clk_period = 15000; /* 66 MHz */
+		t_ces   = 6;
+		t_avds  = 5;
+		t_avdh  = 2;
+		t_ach   = 6;
+		t_aavdh = 6;
+		t_rdyo  = 11;
+		break;
+	default:
+		min_gpmc_clk_period = 18500; /* 54 MHz */
+		t_ces   = 7;
+		t_avds  = 7;
+		t_avdh  = 7;
+		t_ach   = 9;
+		t_aavdh = 7;
+		t_rdyo  = 15;
+		break;
+	}
+
+	/* Set synchronous read timings */
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	if (!s->sync_write) {
+		dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
+		dev_t.t_wpl = t_wpl * 1000;
+		dev_t.t_wph = t_wph * 1000;
+		dev_t.t_aavdh = t_aavdh * 1000;
+	}
+	dev_t.ce_xdelay = true;
+	dev_t.avd_xdelay = true;
+	dev_t.oe_xdelay = true;
+	dev_t.we_xdelay = true;
+	dev_t.clk = min_gpmc_clk_period;
+	dev_t.t_bacc = dev_t.clk;
+	dev_t.t_ces = t_ces * 1000;
+	dev_t.t_avds = t_avds * 1000;
+	dev_t.t_avdh = t_avdh * 1000;
+	dev_t.t_ach = t_ach * 1000;
+	dev_t.cyc_iaa = (latency + 1);
+	dev_t.t_cez_r = t_cez * 1000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.cyc_aavdh_oe = 1;
+	dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
+
+	gpmc_calc_timings(t, s, &dev_t);
+}
+
+int gpmc_omap_onenand_set_timings(struct device *dev, int cs, int freq,
+				  int latency,
+				  struct gpmc_onenand_info *info)
+{
+	int ret;
+	struct gpmc_timings gpmc_t;
+	struct gpmc_settings gpmc_s;
+
+	gpmc_read_settings_dt(dev->of_node, &gpmc_s);
+
+	info->sync_read = gpmc_s.sync_read;
+	info->sync_write = gpmc_s.sync_write;
+	info->burst_len = gpmc_s.burst_len;
+
+	if (!gpmc_s.sync_read && !gpmc_s.sync_write)
+		return 0;
+
+	gpmc_omap_onenand_calc_sync_timings(&gpmc_t, &gpmc_s, freq, latency);
+
+	ret = gpmc_cs_program_settings(cs, &gpmc_s);
+	if (ret < 0)
+		return ret;
+
+	return gpmc_cs_set_timings(cs, &gpmc_t, &gpmc_s);
+}
+EXPORT_SYMBOL_GPL(gpmc_omap_onenand_set_timings);
+
 int gpmc_get_client_irq(unsigned irq_config)
 {
 	if (!gpmc_irq_domain) {
@@ -1916,41 +2021,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct device_node *np,
 		of_property_read_bool(np, "gpmc,time-para-granularity");
 }
 
-#if IS_ENABLED(CONFIG_MTD_ONENAND)
-static int gpmc_probe_onenand_child(struct platform_device *pdev,
-				 struct device_node *child)
-{
-	u32 val;
-	struct omap_onenand_platform_data *gpmc_onenand_data;
-
-	if (of_property_read_u32(child, "reg", &val) < 0) {
-		dev_err(&pdev->dev, "%pOF has no 'reg' property\n",
-			child);
-		return -ENODEV;
-	}
-
-	gpmc_onenand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_onenand_data),
-					 GFP_KERNEL);
-	if (!gpmc_onenand_data)
-		return -ENOMEM;
-
-	gpmc_onenand_data->cs = val;
-	gpmc_onenand_data->of_node = child;
-	gpmc_onenand_data->dma_channel = -1;
-
-	if (!of_property_read_u32(child, "dma-channel", &val))
-		gpmc_onenand_data->dma_channel = val;
-
-	return gpmc_onenand_init(gpmc_onenand_data);
-}
-#else
-static int gpmc_probe_onenand_child(struct platform_device *pdev,
-				    struct device_node *child)
-{
-	return 0;
-}
-#endif
-
 /**
  * gpmc_probe_generic_child - configures the gpmc for a child device
  * @pdev:	pointer to gpmc platform device
@@ -2053,6 +2123,16 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
 		}
 	}
 
+	if (of_node_cmp(child->name, "onenand") == 0) {
+		/* Warn about older DT blobs with no compatible property */
+		if (!of_property_read_bool(child, "compatible")) {
+			dev_warn(&pdev->dev,
+				 "Incompatible OneNAND node: missing compatible");
+			ret = -EINVAL;
+			goto err;
+		}
+	}
+
 	if (of_device_is_compatible(child, "ti,omap2-nand")) {
 		/* NAND specific setup */
 		val = 8;
@@ -2189,11 +2269,7 @@ static void gpmc_probe_dt_children(struct platform_device *pdev)
 		if (!child->name)
 			continue;
 
-		if (of_node_cmp(child->name, "onenand") == 0)
-			ret = gpmc_probe_onenand_child(pdev, child);
-		else
-			ret = gpmc_probe_generic_child(pdev, child);
-
+		ret = gpmc_probe_generic_child(pdev, child);
 		if (ret) {
 			dev_err(&pdev->dev, "failed to probe DT child '%s': %d\n",
 				child->name, ret);
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index edfa280c3d56..067bea5e98c4 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -25,15 +25,40 @@ struct gpmc_nand_ops {
 
 struct gpmc_nand_regs;
 
+struct gpmc_onenand_info {
+	bool sync_read;
+	bool sync_write;
+	int burst_len;
+};
+
 #if IS_ENABLED(CONFIG_OMAP_GPMC)
 struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
 					     int cs);
+/**
+ * gpmc_omap_onenand_set_timings - set optimized sync timings.
+ * @cs:      Chip Select Region
+ * @freq:    Chip frequency
+ * @latency: Burst latency cycle count
+ * @info:    Structure describing parameters used
+ */
+int gpmc_omap_onenand_set_timings(struct device *dev, int cs, int freq,
+				  int latency,
+				  struct gpmc_onenand_info *info);
+
 #else
 static inline struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
 							   int cs)
 {
 	return NULL;
 }
+
+static inline
+int gpmc_omap_onenand_set_timings(struct device *dev, int cs, int freq,
+				  int latency,
+				  struct gpmc_onenand_info *info)
+{
+	return -EINVAL;
+}
 #endif /* CONFIG_OMAP_GPMC */
 
 extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
-- 
2.11.0

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

Hi,

* Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> Use generic probe function to deal with OneNAND node and remove now useless
> gpmc_probe_onenand_child function.
> Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> and prepare for MTD driver DTfication.

I tried giving this series a try on n900, but looks like onenand is no longer
seen on n900 after this first patch.

Regards,

Tony

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

Hi,

* Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> Use generic probe function to deal with OneNAND node and remove now useless
> gpmc_probe_onenand_child function.
> Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> and prepare for MTD driver DTfication.

I tried giving this series a try on n900, but looks like onenand is no longer
seen on n900 after this first patch.

Regards,

Tony

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 09:56:26AM -0800, Tony Lindgren wrote:
> Hi,
> 
> * Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> > Use generic probe function to deal with OneNAND node and remove now useless
> > gpmc_probe_onenand_child function.
> > Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> > and prepare for MTD driver DTfication.
> 
> I tried giving this series a try on n900, but looks like onenand is no longer
> seen on n900 after this first patch.

This first patch makes original driver stop working as it removes special
OneNAND handling. If it doesn't work even after applying whole serie, then:
- verify onenand node has compatible 'ti,omap2-onenand' property
- verify timings

On IGEPv2 bootlog shows:
[    1.544464] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[    1.550415] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[    1.560485] omap2-onenand 30000000.onenand: initializing on CS0, phys base 0x30000000, virtual base e0080000
[    1.571014] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[    1.576507] OneNAND version = 0x0031
[    1.583435] Scanning device for bad blocks
[    1.620971] OneNAND eraseblock 597 is an initial bad block
[    1.657470] OneNAND eraseblock 1159 is an initial bad block
[    1.754577] OneNAND eraseblock 2812 is an initial bad block
[    1.832214] omap2-onenand 30000000.onenand: optimized timings for 83 MHz
[    1.842620] 2 ofpart partitions found on MTD device 30000000.onenand
[    1.849426] Creating 2 MTD partitions on "30000000.onenand":
[    1.855651] 0x000000000000-0x000000080000 : "SPL"
[    1.863464] 0x000000080000-0x000020000000 : "UBI"

For a start:

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 4acd32a1c4ef..aa5b1a439564 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -838,6 +838,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 09:56:26AM -0800, Tony Lindgren wrote:
> Hi,
> 
> * Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> > Use generic probe function to deal with OneNAND node and remove now useless
> > gpmc_probe_onenand_child function.
> > Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> > and prepare for MTD driver DTfication.
> 
> I tried giving this series a try on n900, but looks like onenand is no longer
> seen on n900 after this first patch.

This first patch makes original driver stop working as it removes special
OneNAND handling. If it doesn't work even after applying whole serie, then:
- verify onenand node has compatible 'ti,omap2-onenand' property
- verify timings

On IGEPv2 bootlog shows:
[    1.544464] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
[    1.550415] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
[    1.560485] omap2-onenand 30000000.onenand: initializing on CS0, phys base 0x30000000, virtual base e0080000
[    1.571014] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
[    1.576507] OneNAND version = 0x0031
[    1.583435] Scanning device for bad blocks
[    1.620971] OneNAND eraseblock 597 is an initial bad block
[    1.657470] OneNAND eraseblock 1159 is an initial bad block
[    1.754577] OneNAND eraseblock 2812 is an initial bad block
[    1.832214] omap2-onenand 30000000.onenand: optimized timings for 83 MHz
[    1.842620] 2 ofpart partitions found on MTD device 30000000.onenand
[    1.849426] Creating 2 MTD partitions on "30000000.onenand":
[    1.855651] 0x000000000000-0x000000080000 : "SPL"
[    1.863464] 0x000000080000-0x000020000000 : "UBI"

For a start:

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 4acd32a1c4ef..aa5b1a439564 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -838,6 +838,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171109 18:11]:
> On Thu, Nov 09, 2017 at 09:56:26AM -0800, Tony Lindgren wrote:
> > Hi,
> > 
> > * Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> > > Use generic probe function to deal with OneNAND node and remove now useless
> > > gpmc_probe_onenand_child function.
> > > Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> > > and prepare for MTD driver DTfication.
> > 
> > I tried giving this series a try on n900, but looks like onenand is no longer
> > seen on n900 after this first patch.
> 
> This first patch makes original driver stop working as it removes special
> OneNAND handling. If it doesn't work even after applying whole serie, then:
> - verify onenand node has compatible 'ti,omap2-onenand' property
> - verify timings
> 
> On IGEPv2 bootlog shows:
> [    1.544464] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> [    1.550415] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> [    1.560485] omap2-onenand 30000000.onenand: initializing on CS0, phys base 0x30000000, virtual base e0080000
> [    1.571014] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> [    1.576507] OneNAND version = 0x0031
> [    1.583435] Scanning device for bad blocks
> [    1.620971] OneNAND eraseblock 597 is an initial bad block
> [    1.657470] OneNAND eraseblock 1159 is an initial bad block
> [    1.754577] OneNAND eraseblock 2812 is an initial bad block
> [    1.832214] omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> [    1.842620] 2 ofpart partitions found on MTD device 30000000.onenand
> [    1.849426] Creating 2 MTD partitions on "30000000.onenand":
> [    1.855651] 0x000000000000-0x000000080000 : "SPL"
> [    1.863464] 0x000000080000-0x000020000000 : "UBI"
> 
> For a start:
> 
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 4acd32a1c4ef..aa5b1a439564 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -838,6 +838,7 @@
>  	onenand@0,0 {
>  		#address-cells = <1>;
>  		#size-cells = <1>;
> +		compatible = "ti,omap2-onenand";
>  		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
>  
>  		gpmc,sync-read;

Well we should have the dependencies merged first to avoid breaking
git bisect. After applying this and the first patch I see:

omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22

So seems like more dts changes are needed to test this.

Regards,

Tony

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171109 18:11]:
> On Thu, Nov 09, 2017 at 09:56:26AM -0800, Tony Lindgren wrote:
> > Hi,
> > 
> > * Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> > > Use generic probe function to deal with OneNAND node and remove now useless
> > > gpmc_probe_onenand_child function.
> > > Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> > > and prepare for MTD driver DTfication.
> > 
> > I tried giving this series a try on n900, but looks like onenand is no longer
> > seen on n900 after this first patch.
> 
> This first patch makes original driver stop working as it removes special
> OneNAND handling. If it doesn't work even after applying whole serie, then:
> - verify onenand node has compatible 'ti,omap2-onenand' property
> - verify timings
> 
> On IGEPv2 bootlog shows:
> [    1.544464] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> [    1.550415] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> [    1.560485] omap2-onenand 30000000.onenand: initializing on CS0, phys base 0x30000000, virtual base e0080000
> [    1.571014] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> [    1.576507] OneNAND version = 0x0031
> [    1.583435] Scanning device for bad blocks
> [    1.620971] OneNAND eraseblock 597 is an initial bad block
> [    1.657470] OneNAND eraseblock 1159 is an initial bad block
> [    1.754577] OneNAND eraseblock 2812 is an initial bad block
> [    1.832214] omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> [    1.842620] 2 ofpart partitions found on MTD device 30000000.onenand
> [    1.849426] Creating 2 MTD partitions on "30000000.onenand":
> [    1.855651] 0x000000000000-0x000000080000 : "SPL"
> [    1.863464] 0x000000080000-0x000020000000 : "UBI"
> 
> For a start:
> 
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 4acd32a1c4ef..aa5b1a439564 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -838,6 +838,7 @@
>  	onenand@0,0 {
>  		#address-cells = <1>;
>  		#size-cells = <1>;
> +		compatible = "ti,omap2-onenand";
>  		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
>  
>  		gpmc,sync-read;

Well we should have the dependencies merged first to avoid breaking
git bisect. After applying this and the first patch I see:

omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22

So seems like more dts changes are needed to test this.

Regards,

Tony

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 18:11]:
> > On Thu, Nov 09, 2017 at 09:56:26AM -0800, Tony Lindgren wrote:
> > > Hi,
> > > 
> > > * Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> > > > Use generic probe function to deal with OneNAND node and remove now useless
> > > > gpmc_probe_onenand_child function.
> > > > Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> > > > and prepare for MTD driver DTfication.
> > > 
> > > I tried giving this series a try on n900, but looks like onenand is no longer
> > > seen on n900 after this first patch.
> > 
> > This first patch makes original driver stop working as it removes special
> > OneNAND handling. If it doesn't work even after applying whole serie, then:
> > - verify onenand node has compatible 'ti,omap2-onenand' property
> > - verify timings
> > 
> > On IGEPv2 bootlog shows:
> > [    1.544464] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> > [    1.550415] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> > [    1.560485] omap2-onenand 30000000.onenand: initializing on CS0, phys base 0x30000000, virtual base e0080000
> > [    1.571014] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> > [    1.576507] OneNAND version = 0x0031
> > [    1.583435] Scanning device for bad blocks
> > [    1.620971] OneNAND eraseblock 597 is an initial bad block
> > [    1.657470] OneNAND eraseblock 1159 is an initial bad block
> > [    1.754577] OneNAND eraseblock 2812 is an initial bad block
> > [    1.832214] omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> > [    1.842620] 2 ofpart partitions found on MTD device 30000000.onenand
> > [    1.849426] Creating 2 MTD partitions on "30000000.onenand":
> > [    1.855651] 0x000000000000-0x000000080000 : "SPL"
> > [    1.863464] 0x000000080000-0x000020000000 : "UBI"
> > 
> > For a start:
> > 
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> > index 4acd32a1c4ef..aa5b1a439564 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -838,6 +838,7 @@
> >  	onenand@0,0 {
> >  		#address-cells = <1>;
> >  		#size-cells = <1>;
> > +		compatible = "ti,omap2-onenand";
> >  		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
> >  
> >  		gpmc,sync-read;
> 
> Well we should have the dependencies merged first to avoid breaking

Yes, that's what cover letter says :-)
Also, I still count on your suggestion to merge it via mtd tree.

> git bisect. After applying this and the first patch I see:
> 
> omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
> omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
> 
> So seems like more dts changes are needed to test this.

Argh... You are right, I should add this into serie:
https://patchwork.kernel.org/patch/10043259/

> Regards,
> 
> Tony

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 18:11]:
> > On Thu, Nov 09, 2017 at 09:56:26AM -0800, Tony Lindgren wrote:
> > > Hi,
> > > 
> > > * Ladislav Michl <ladis@linux-mips.org> [171109 09:14]:
> > > > Use generic probe function to deal with OneNAND node and remove now useless
> > > > gpmc_probe_onenand_child function.
> > > > Import sync mode timing calculation function from mach-omap2/gpmc-onenand.c
> > > > and prepare for MTD driver DTfication.
> > > 
> > > I tried giving this series a try on n900, but looks like onenand is no longer
> > > seen on n900 after this first patch.
> > 
> > This first patch makes original driver stop working as it removes special
> > OneNAND handling. If it doesn't work even after applying whole serie, then:
> > - verify onenand node has compatible 'ti,omap2-onenand' property
> > - verify timings
> > 
> > On IGEPv2 bootlog shows:
> > [    1.544464] omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> > [    1.550415] gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> > [    1.560485] omap2-onenand 30000000.onenand: initializing on CS0, phys base 0x30000000, virtual base e0080000
> > [    1.571014] Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> > [    1.576507] OneNAND version = 0x0031
> > [    1.583435] Scanning device for bad blocks
> > [    1.620971] OneNAND eraseblock 597 is an initial bad block
> > [    1.657470] OneNAND eraseblock 1159 is an initial bad block
> > [    1.754577] OneNAND eraseblock 2812 is an initial bad block
> > [    1.832214] omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> > [    1.842620] 2 ofpart partitions found on MTD device 30000000.onenand
> > [    1.849426] Creating 2 MTD partitions on "30000000.onenand":
> > [    1.855651] 0x000000000000-0x000000080000 : "SPL"
> > [    1.863464] 0x000000080000-0x000020000000 : "UBI"
> > 
> > For a start:
> > 
> > diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> > index 4acd32a1c4ef..aa5b1a439564 100644
> > --- a/arch/arm/boot/dts/omap3-n900.dts
> > +++ b/arch/arm/boot/dts/omap3-n900.dts
> > @@ -838,6 +838,7 @@
> >  	onenand@0,0 {
> >  		#address-cells = <1>;
> >  		#size-cells = <1>;
> > +		compatible = "ti,omap2-onenand";
> >  		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
> >  
> >  		gpmc,sync-read;
> 
> Well we should have the dependencies merged first to avoid breaking

Yes, that's what cover letter says :-)
Also, I still count on your suggestion to merge it via mtd tree.

> git bisect. After applying this and the first patch I see:
> 
> omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
> omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
> 
> So seems like more dts changes are needed to test this.

Argh... You are right, I should add this into serie:
https://patchwork.kernel.org/patch/10043259/

> Regards,
> 
> Tony

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171109 18:35]:
> On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
> > Well we should have the dependencies merged first to avoid breaking
> 
> Yes, that's what cover letter says :-)
> Also, I still count on your suggestion to merge it via mtd tree.

Well only after it has been tested :) At this point I'd say
we're best off waiting for v4.16 merge window on the clean
up too as the merge window is about to open.

> > git bisect. After applying this and the first patch I see:
> > 
> > omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
> > omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
> > 
> > So seems like more dts changes are needed to test this.
> 
> Argh... You are right, I should add this into serie:
> https://patchwork.kernel.org/patch/10043259/

Well don't we still need the related dts changes posted
and merged first?

Regards,

Tony

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171109 18:35]:
> On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
> > Well we should have the dependencies merged first to avoid breaking
> 
> Yes, that's what cover letter says :-)
> Also, I still count on your suggestion to merge it via mtd tree.

Well only after it has been tested :) At this point I'd say
we're best off waiting for v4.16 merge window on the clean
up too as the merge window is about to open.

> > git bisect. After applying this and the first patch I see:
> > 
> > omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
> > omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
> > 
> > So seems like more dts changes are needed to test this.
> 
> Argh... You are right, I should add this into serie:
> https://patchwork.kernel.org/patch/10043259/

Well don't we still need the related dts changes posted
and merged first?

Regards,

Tony

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 10:48:28AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 18:35]:
> > On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
> > > Well we should have the dependencies merged first to avoid breaking
> > 
> > Yes, that's what cover letter says :-)
> > Also, I still count on your suggestion to merge it via mtd tree.
> 
> Well only after it has been tested :) At this point I'd say
> we're best off waiting for v4.16 merge window on the clean
> up too as the merge window is about to open.
> 
> > > git bisect. After applying this and the first patch I see:
> > > 
> > > omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
> > > omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
> > > 
> > > So seems like more dts changes are needed to test this.
> > 
> > Argh... You are right, I should add this into serie:
> > https://patchwork.kernel.org/patch/10043259/
> 
> Well don't we still need the related dts changes posted
> and merged first?

Well, except Roger's feedback, there were complete silence so far.
Note that simple fix was posted in February, this was rejected as
we should aim towards clean DT only driver. And here we are with
some doubts.

As I have no hardware nor any special knowledge going prior
initial driver commit it is rather hard to send "related dts changes"
given simple fact, that I'm unsure whenever we need to distinguish
between OMAP2 and OMAP3. Based on that we need either one or
two compatible strings.

Having two is safe, but u-boot will be unable to bring onenand equipped
igep up.

	ladis

> Regards,
> 
> Tony

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 10:48:28AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 18:35]:
> > On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
> > > Well we should have the dependencies merged first to avoid breaking
> > 
> > Yes, that's what cover letter says :-)
> > Also, I still count on your suggestion to merge it via mtd tree.
> 
> Well only after it has been tested :) At this point I'd say
> we're best off waiting for v4.16 merge window on the clean
> up too as the merge window is about to open.
> 
> > > git bisect. After applying this and the first patch I see:
> > > 
> > > omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
> > > omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
> > > 
> > > So seems like more dts changes are needed to test this.
> > 
> > Argh... You are right, I should add this into serie:
> > https://patchwork.kernel.org/patch/10043259/
> 
> Well don't we still need the related dts changes posted
> and merged first?

Well, except Roger's feedback, there were complete silence so far.
Note that simple fix was posted in February, this was rejected as
we should aim towards clean DT only driver. And here we are with
some doubts.

As I have no hardware nor any special knowledge going prior
initial driver commit it is rather hard to send "related dts changes"
given simple fact, that I'm unsure whenever we need to distinguish
between OMAP2 and OMAP3. Based on that we need either one or
two compatible strings.

Having two is safe, but u-boot will be unable to bring onenand equipped
igep up.

	ladis

> Regards,
> 
> Tony

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171109 19:12]:
> On Thu, Nov 09, 2017 at 10:48:28AM -0800, Tony Lindgren wrote:
> > Well don't we still need the related dts changes posted
> > and merged first?
> 
> Well, except Roger's feedback, there were complete silence so far.
> Note that simple fix was posted in February, this was rejected as
> we should aim towards clean DT only driver. And here we are with
> some doubts.
> 
> As I have no hardware nor any special knowledge going prior
> initial driver commit it is rather hard to send "related dts changes"
> given simple fact, that I'm unsure whenever we need to distinguish
> between OMAP2 and OMAP3. Based on that we need either one or
> two compatible strings.
> 
> Having two is safe, but u-boot will be unable to bring onenand equipped
> igep up.

Well if you have a complete series with proposed dts changes for
n8x0 and n900, I can try to test those. My n800 seems to have stopped
booting today.. Maybe I need to reflash it after playing with onenand.

Regards,

Tony

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171109 19:12]:
> On Thu, Nov 09, 2017 at 10:48:28AM -0800, Tony Lindgren wrote:
> > Well don't we still need the related dts changes posted
> > and merged first?
> 
> Well, except Roger's feedback, there were complete silence so far.
> Note that simple fix was posted in February, this was rejected as
> we should aim towards clean DT only driver. And here we are with
> some doubts.
> 
> As I have no hardware nor any special knowledge going prior
> initial driver commit it is rather hard to send "related dts changes"
> given simple fact, that I'm unsure whenever we need to distinguish
> between OMAP2 and OMAP3. Based on that we need either one or
> two compatible strings.
> 
> Having two is safe, but u-boot will be unable to bring onenand equipped
> igep up.

Well if you have a complete series with proposed dts changes for
n8x0 and n900, I can try to test those. My n800 seems to have stopped
booting today.. Maybe I need to reflash it after playing with onenand.

Regards,

Tony

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 01:59:53PM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 19:12]:
> > On Thu, Nov 09, 2017 at 10:48:28AM -0800, Tony Lindgren wrote:
> > > Well don't we still need the related dts changes posted
> > > and merged first?
> > 
> > Well, except Roger's feedback, there were complete silence so far.
> > Note that simple fix was posted in February, this was rejected as
> > we should aim towards clean DT only driver. And here we are with
> > some doubts.
> > 
> > As I have no hardware nor any special knowledge going prior
> > initial driver commit it is rather hard to send "related dts changes"
> > given simple fact, that I'm unsure whenever we need to distinguish
> > between OMAP2 and OMAP3. Based on that we need either one or
> > two compatible strings.
> > 
> > Having two is safe, but u-boot will be unable to bring onenand equipped
> > igep up.
> 
> Well if you have a complete series with proposed dts changes for
> n8x0 and n900, I can try to test those. My n800 seems to have stopped
> booting today.. Maybe I need to reflash it after playing with onenand.

Okay, here's quick dts patch. Other than that you need:
https://patchwork.kernel.org/patch/10043259/

If you possibly get it working, we can try enable DMA, which is where
things start to be interesting. Once we get DMA working on both
OMAP2 and OMAP3, we are safe to provide only one compatible string.
But that seems to be very long run as even original driver author
left DMA disabled for OMAP2 :-(

Another option is to just ignore OMAP2 DMA which is rather easy:
just omit gpio in dts.

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 1de80c7886ab..843f6a2f5e29 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -48,6 +48,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 4acd32a1c4ef..aa5b1a439564 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -838,6 +838,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 1b0bd72945f2..cb3c7b2fce52 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -367,6 +367,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index d50a105c9dc6..ed65795ccc62 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -155,6 +155,7 @@
 		linux,mtd-name= "samsung,kfm2g16q2m-deb8";
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <2 0 0x20000>;	/* CS2, offset 0, IO size 4 */
 
 		gpmc,device-width = <2>;

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Ladislav Michl]

On Thu, Nov 09, 2017 at 01:59:53PM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 19:12]:
> > On Thu, Nov 09, 2017 at 10:48:28AM -0800, Tony Lindgren wrote:
> > > Well don't we still need the related dts changes posted
> > > and merged first?
> > 
> > Well, except Roger's feedback, there were complete silence so far.
> > Note that simple fix was posted in February, this was rejected as
> > we should aim towards clean DT only driver. And here we are with
> > some doubts.
> > 
> > As I have no hardware nor any special knowledge going prior
> > initial driver commit it is rather hard to send "related dts changes"
> > given simple fact, that I'm unsure whenever we need to distinguish
> > between OMAP2 and OMAP3. Based on that we need either one or
> > two compatible strings.
> > 
> > Having two is safe, but u-boot will be unable to bring onenand equipped
> > igep up.
> 
> Well if you have a complete series with proposed dts changes for
> n8x0 and n900, I can try to test those. My n800 seems to have stopped
> booting today.. Maybe I need to reflash it after playing with onenand.

Okay, here's quick dts patch. Other than that you need:
https://patchwork.kernel.org/patch/10043259/

If you possibly get it working, we can try enable DMA, which is where
things start to be interesting. Once we get DMA working on both
OMAP2 and OMAP3, we are safe to provide only one compatible string.
But that seems to be very long run as even original driver author
left DMA disabled for OMAP2 :-(

Another option is to just ignore OMAP2 DMA which is rather easy:
just omit gpio in dts.

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index 1de80c7886ab..843f6a2f5e29 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -48,6 +48,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 4acd32a1c4ef..aa5b1a439564 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -838,6 +838,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;
diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 1b0bd72945f2..cb3c7b2fce52 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -367,6 +367,7 @@
 	onenand@0,0 {
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <0 0 0x20000>;	/* CS0, offset 0, IO size 128K */
 
 		gpmc,sync-read;
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts b/arch/arm/boot/dts/omap3430-sdp.dts
index d50a105c9dc6..ed65795ccc62 100644
--- a/arch/arm/boot/dts/omap3430-sdp.dts
+++ b/arch/arm/boot/dts/omap3430-sdp.dts
@@ -155,6 +155,7 @@
 		linux,mtd-name= "samsung,kfm2g16q2m-deb8";
 		#address-cells = <1>;
 		#size-cells = <1>;
+		compatible = "ti,omap2-onenand";
 		reg = <2 0 0x20000>;	/* CS2, offset 0, IO size 4 */
 
 		gpmc,device-width = <2>;

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Roger Quadros]

On 09/11/17 20:48, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 18:35]:
>> On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
>>> Well we should have the dependencies merged first to avoid breaking
>>
>> Yes, that's what cover letter says :-)
>> Also, I still count on your suggestion to merge it via mtd tree.
> 
> Well only after it has been tested :) At this point I'd say
> we're best off waiting for v4.16 merge window on the clean
> up too as the merge window is about to open.
> 
>>> git bisect. After applying this and the first patch I see:
>>>
>>> omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
>>> omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
>>>
>>> So seems like more dts changes are needed to test this.
>>
>> Argh... You are right, I should add this into serie:
>> https://patchwork.kernel.org/patch/10043259/

You don't need to resend that patch as it has been already
reviewed and in my v4.16 queue. Just indicate in the cover letter that this
series depends on that patch.

> 
> Well don't we still need the related dts changes posted
> and merged first> 
> Regards,
> 
> Tony
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 1/7] memory: omap-gpmc: Refactor OneNAND support

[Roger Quadros]

On 09/11/17 20:48, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171109 18:35]:
>> On Thu, Nov 09, 2017 at 10:26:45AM -0800, Tony Lindgren wrote:
>>> Well we should have the dependencies merged first to avoid breaking
>>
>> Yes, that's what cover letter says :-)
>> Also, I still count on your suggestion to merge it via mtd tree.
> 
> Well only after it has been tested :) At this point I'd say
> we're best off waiting for v4.16 merge window on the clean
> up too as the merge window is about to open.
> 
>>> git bisect. After applying this and the first patch I see:
>>>
>>> omap-gpmc 6e000000.gpmc: /ocp@68000000/gpmc@6e000000/onenand@0,0 has no 'bank-width' property
>>> omap-gpmc 6e000000.gpmc: failed to probe DT child 'onenand': -22
>>>
>>> So seems like more dts changes are needed to test this.
>>
>> Argh... You are right, I should add this into serie:
>> https://patchwork.kernel.org/patch/10043259/

You don't need to resend that patch as it has been already
reviewed and in my v4.16 queue. Just indicate in the cover letter that this
series depends on that patch.

> 
> Well don't we still need the related dts changes posted
> and merged first> 
> Regards,
> 
> Tony
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH v3 2/7] mtd: onenand: omap2: Remove regulator support

[Ladislav Michl]

As no platform data user sets regulator_can_sleep, regulator code is
no-op and can be deleted.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: new patch
 -v3: none

 drivers/mtd/onenand/omap2.c | 42 +-----------------------------------------
 1 file changed, 1 insertion(+), 41 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 24a1388d3031..a03e1fe4aa48 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -34,7 +34,6 @@
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/slab.h>
-#include <linux/regulator/consumer.h>
 #include <linux/gpio.h>
 
 #include <asm/mach/flash.h>
@@ -59,7 +58,6 @@ struct omap2_onenand {
 	int dma_channel;
 	int freq;
 	int (*setup)(void __iomem *base, int *freq_ptr);
-	struct regulator *regulator;
 	u8 flags;
 };
 
@@ -583,30 +581,6 @@ static void omap2_onenand_shutdown(struct platform_device *pdev)
 	memset((__force void *)c->onenand.base, 0, ONENAND_BUFRAM_SIZE);
 }
 
-static int omap2_onenand_enable(struct mtd_info *mtd)
-{
-	int ret;
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-
-	ret = regulator_enable(c->regulator);
-	if (ret != 0)
-		dev_err(&c->pdev->dev, "can't enable regulator\n");
-
-	return ret;
-}
-
-static int omap2_onenand_disable(struct mtd_info *mtd)
-{
-	int ret;
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-
-	ret = regulator_disable(c->regulator);
-	if (ret != 0)
-		dev_err(&c->pdev->dev, "can't disable regulator\n");
-
-	return ret;
-}
-
 static int omap2_onenand_probe(struct platform_device *pdev)
 {
 	struct omap_onenand_platform_data *pdata;
@@ -726,22 +700,11 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 		}
 	}
 
-	if (pdata->regulator_can_sleep) {
-		c->regulator = regulator_get(&pdev->dev, "vonenand");
-		if (IS_ERR(c->regulator)) {
-			dev_err(&pdev->dev,  "Failed to get regulator\n");
-			r = PTR_ERR(c->regulator);
-			goto err_release_dma;
-		}
-		c->onenand.enable = omap2_onenand_enable;
-		c->onenand.disable = omap2_onenand_disable;
-	}
-
 	if (pdata->skip_initial_unlocking)
 		this->options |= ONENAND_SKIP_INITIAL_UNLOCKING;
 
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
-		goto err_release_regulator;
+		goto err_release_dma;
 
 	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
 				pdata ? pdata->nr_parts : 0);
@@ -754,8 +717,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 
 err_release_onenand:
 	onenand_release(&c->mtd);
-err_release_regulator:
-	regulator_put(c->regulator);
 err_release_dma:
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
@@ -779,7 +740,6 @@ static int omap2_onenand_remove(struct platform_device *pdev)
 	struct omap2_onenand *c = dev_get_drvdata(&pdev->dev);
 
 	onenand_release(&c->mtd);
-	regulator_put(c->regulator);
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
 	omap2_onenand_shutdown(pdev);
-- 
2.11.0


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

[PATCH v3 2/7] mtd: onenand: omap2: Remove regulator support

[Ladislav Michl]

As no platform data user sets regulator_can_sleep, regulator code is
no-op and can be deleted.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: new patch
 -v3: none

 drivers/mtd/onenand/omap2.c | 42 +-----------------------------------------
 1 file changed, 1 insertion(+), 41 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 24a1388d3031..a03e1fe4aa48 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -34,7 +34,6 @@
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/slab.h>
-#include <linux/regulator/consumer.h>
 #include <linux/gpio.h>
 
 #include <asm/mach/flash.h>
@@ -59,7 +58,6 @@ struct omap2_onenand {
 	int dma_channel;
 	int freq;
 	int (*setup)(void __iomem *base, int *freq_ptr);
-	struct regulator *regulator;
 	u8 flags;
 };
 
@@ -583,30 +581,6 @@ static void omap2_onenand_shutdown(struct platform_device *pdev)
 	memset((__force void *)c->onenand.base, 0, ONENAND_BUFRAM_SIZE);
 }
 
-static int omap2_onenand_enable(struct mtd_info *mtd)
-{
-	int ret;
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-
-	ret = regulator_enable(c->regulator);
-	if (ret != 0)
-		dev_err(&c->pdev->dev, "can't enable regulator\n");
-
-	return ret;
-}
-
-static int omap2_onenand_disable(struct mtd_info *mtd)
-{
-	int ret;
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-
-	ret = regulator_disable(c->regulator);
-	if (ret != 0)
-		dev_err(&c->pdev->dev, "can't disable regulator\n");
-
-	return ret;
-}
-
 static int omap2_onenand_probe(struct platform_device *pdev)
 {
 	struct omap_onenand_platform_data *pdata;
@@ -726,22 +700,11 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 		}
 	}
 
-	if (pdata->regulator_can_sleep) {
-		c->regulator = regulator_get(&pdev->dev, "vonenand");
-		if (IS_ERR(c->regulator)) {
-			dev_err(&pdev->dev,  "Failed to get regulator\n");
-			r = PTR_ERR(c->regulator);
-			goto err_release_dma;
-		}
-		c->onenand.enable = omap2_onenand_enable;
-		c->onenand.disable = omap2_onenand_disable;
-	}
-
 	if (pdata->skip_initial_unlocking)
 		this->options |= ONENAND_SKIP_INITIAL_UNLOCKING;
 
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
-		goto err_release_regulator;
+		goto err_release_dma;
 
 	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
 				pdata ? pdata->nr_parts : 0);
@@ -754,8 +717,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 
 err_release_onenand:
 	onenand_release(&c->mtd);
-err_release_regulator:
-	regulator_put(c->regulator);
 err_release_dma:
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
@@ -779,7 +740,6 @@ static int omap2_onenand_remove(struct platform_device *pdev)
 	struct omap2_onenand *c = dev_get_drvdata(&pdev->dev);
 
 	onenand_release(&c->mtd);
-	regulator_put(c->regulator);
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
 	omap2_onenand_shutdown(pdev);
-- 
2.11.0

Re: [PATCH v3 2/7] mtd: onenand: omap2: Remove regulator support

[Roger Quadros]

Hi,

On 09/11/17 11:13, Ladislav Michl wrote:
> As no platform data user sets regulator_can_sleep, regulator code is
> no-op and can be deleted.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v2: new patch
>  -v3: none
> 
>  drivers/mtd/onenand/omap2.c | 42 +-----------------------------------------
>  1 file changed, 1 insertion(+), 41 deletions(-)

How about getting rid of regulator_can_sleep from
include/linux/platform_data/mtd-onenand-omap2.h?


> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c

<snip>

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 2/7] mtd: onenand: omap2: Remove regulator support

[Roger Quadros]

Hi,

On 09/11/17 11:13, Ladislav Michl wrote:
> As no platform data user sets regulator_can_sleep, regulator code is
> no-op and can be deleted.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v2: new patch
>  -v3: none
> 
>  drivers/mtd/onenand/omap2.c | 42 +-----------------------------------------
>  1 file changed, 1 insertion(+), 41 deletions(-)

How about getting rid of regulator_can_sleep from
include/linux/platform_data/mtd-onenand-omap2.h?


> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c

<snip>

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH v3 3/7] mtd: onenand: omap2: Remove skip initial unlocking support

[Ladislav Michl]

No platform data user sets skip_initial_unlocking, so remove test
for this field.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: new patch
 -v3: none

 drivers/mtd/onenand/omap2.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index a03e1fe4aa48..93bd94337b35 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -700,9 +700,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 		}
 	}
 
-	if (pdata->skip_initial_unlocking)
-		this->options |= ONENAND_SKIP_INITIAL_UNLOCKING;
-
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
 		goto err_release_dma;
 
-- 
2.11.0


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

[PATCH v3 3/7] mtd: onenand: omap2: Remove skip initial unlocking support

[Ladislav Michl]

No platform data user sets skip_initial_unlocking, so remove test
for this field.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: new patch
 -v3: none

 drivers/mtd/onenand/omap2.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index a03e1fe4aa48..93bd94337b35 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -700,9 +700,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 		}
 	}
 
-	if (pdata->skip_initial_unlocking)
-		this->options |= ONENAND_SKIP_INITIAL_UNLOCKING;
-
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
 		goto err_release_dma;
 
-- 
2.11.0

Re: [PATCH v3 3/7] mtd: onenand: omap2: Remove skip initial unlocking support

[Roger Quadros]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 09/11/17 11:14, Ladislav Michl wrote:
> No platform data user sets skip_initial_unlocking, so remove test
> for this field.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v2: new patch
>  -v3: none
> 
>  drivers/mtd/onenand/omap2.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index a03e1fe4aa48..93bd94337b35 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -700,9 +700,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> -	if (pdata->skip_initial_unlocking)
> -		this->options |= ONENAND_SKIP_INITIAL_UNLOCKING;
> -
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
>  		goto err_release_dma;
>  
> 

Let's get rid of 'skip_initial_unlocking' from platform_data as well.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


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

Re: [PATCH v3 3/7] mtd: onenand: omap2: Remove skip initial unlocking support

[Roger Quadros]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 09/11/17 11:14, Ladislav Michl wrote:
> No platform data user sets skip_initial_unlocking, so remove test
> for this field.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v2: new patch
>  -v3: none
> 
>  drivers/mtd/onenand/omap2.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index a03e1fe4aa48..93bd94337b35 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -700,9 +700,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  		}
>  	}
>  
> -	if (pdata->skip_initial_unlocking)
> -		this->options |= ONENAND_SKIP_INITIAL_UNLOCKING;
> -
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
>  		goto err_release_dma;
>  
> 

Let's get rid of 'skip_initial_unlocking' from platform_data as well.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH v3 4/7] mtd: onenand: omap2: Remove partitioning support from platform data

[Ladislav Michl]

No platform data user setups partitioning informations, so remove.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: new patch
 -v3: none

 drivers/mtd/onenand/omap2.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 93bd94337b35..883993bbe40b 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -703,8 +703,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
 		goto err_release_dma;
 
-	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
-				pdata ? pdata->nr_parts : 0);
+	r = mtd_device_register(&c->mtd, NULL, 0);
 	if (r)
 		goto err_release_onenand;
 
-- 
2.11.0


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

[PATCH v3 4/7] mtd: onenand: omap2: Remove partitioning support from platform data

[Ladislav Michl]

No platform data user setups partitioning informations, so remove.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: new patch
 -v3: none

 drivers/mtd/onenand/omap2.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 93bd94337b35..883993bbe40b 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -703,8 +703,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
 		goto err_release_dma;
 
-	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
-				pdata ? pdata->nr_parts : 0);
+	r = mtd_device_register(&c->mtd, NULL, 0);
 	if (r)
 		goto err_release_onenand;
 
-- 
2.11.0

Re: [PATCH v3 4/7] mtd: onenand: omap2: Remove partitioning support from platform data

[Roger Quadros]

On 09/11/17 11:14, Ladislav Michl wrote:
> No platform data user setups partitioning informations, so remove.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v2: new patch
>  -v3: none
> 
>  drivers/mtd/onenand/omap2.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 93bd94337b35..883993bbe40b 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -703,8 +703,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
>  		goto err_release_dma;
>  
> -	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
> -				pdata ? pdata->nr_parts : 0);
> +	r = mtd_device_register(&c->mtd, NULL, 0);
>  	if (r)
>  		goto err_release_onenand;
>  
> 

Same here. Need to update platform data structure.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 4/7] mtd: onenand: omap2: Remove partitioning support from platform data

[Roger Quadros]

On 09/11/17 11:14, Ladislav Michl wrote:
> No platform data user setups partitioning informations, so remove.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v2: new patch
>  -v3: none
> 
>  drivers/mtd/onenand/omap2.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 93bd94337b35..883993bbe40b 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -703,8 +703,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
>  		goto err_release_dma;
>  
> -	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
> -				pdata ? pdata->nr_parts : 0);
> +	r = mtd_device_register(&c->mtd, NULL, 0);
>  	if (r)
>  		goto err_release_onenand;
>  
> 

Same here. Need to update platform data structure.

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 4/7] mtd: onenand: omap2: Remove partitioning support from platform data

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:19:11AM +0200, Roger Quadros wrote:
> On 09/11/17 11:14, Ladislav Michl wrote:
> > No platform data user setups partitioning informations, so remove.
> > 
> > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > ---
> >  Changes:
> >  -v2: new patch
> >  -v3: none
> > 
> >  drivers/mtd/onenand/omap2.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> > index 93bd94337b35..883993bbe40b 100644
> > --- a/drivers/mtd/onenand/omap2.c
> > +++ b/drivers/mtd/onenand/omap2.c
> > @@ -703,8 +703,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
> >  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> >  		goto err_release_dma;
> >  
> > -	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
> > -				pdata ? pdata->nr_parts : 0);
> > +	r = mtd_device_register(&c->mtd, NULL, 0);
> >  	if (r)
> >  		goto err_release_onenand;
> >  
> > 
> 
> Same here. Need to update platform data structure.

I do not want to unnecessarily extend patch as I hope no sane maintainer
would ever allow anyone to add any new platform data dependency while
we are moving towards DT only configured kernel.

Platform data structure will be deleted entirely together with
arch/arm/mach-omap2/gpmc-onenand.c once driver update gets accepted.

	ladis

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

Re: [PATCH v3 4/7] mtd: onenand: omap2: Remove partitioning support from platform data

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:19:11AM +0200, Roger Quadros wrote:
> On 09/11/17 11:14, Ladislav Michl wrote:
> > No platform data user setups partitioning informations, so remove.
> > 
> > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > ---
> >  Changes:
> >  -v2: new patch
> >  -v3: none
> > 
> >  drivers/mtd/onenand/omap2.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> > index 93bd94337b35..883993bbe40b 100644
> > --- a/drivers/mtd/onenand/omap2.c
> > +++ b/drivers/mtd/onenand/omap2.c
> > @@ -703,8 +703,7 @@ static int omap2_onenand_probe(struct platform_device *pdev)
> >  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> >  		goto err_release_dma;
> >  
> > -	r = mtd_device_register(&c->mtd, pdata ? pdata->parts : NULL,
> > -				pdata ? pdata->nr_parts : 0);
> > +	r = mtd_device_register(&c->mtd, NULL, 0);
> >  	if (r)
> >  		goto err_release_onenand;
> >  
> > 
> 
> Same here. Need to update platform data structure.

I do not want to unnecessarily extend patch as I hope no sane maintainer
would ever allow anyone to add any new platform data dependency while
we are moving towards DT only configured kernel.

Platform data structure will be deleted entirely together with
arch/arm/mach-omap2/gpmc-onenand.c once driver update gets accepted.

	ladis

[PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
Therefore replace open coded timeout waiting for completion in OMAP3
functions with API call and merge those two implementations.

Note that currently the is no single DMA user, so this change is basically
no-op. Those interested will have to find DMA configuration in the
linux-omap.git history.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v3: new patch

 drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
 1 file changed, 10 insertions(+), 155 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 883993bbe40b..5760e40be008 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
 	return 0;
 }
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
-
-static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
+static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
 					unsigned char *buffer, int offset,
 					size_t count)
 {
@@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
 	struct onenand_chip *this = mtd->priv;
 	dma_addr_t dma_src, dma_dst;
 	int bram_offset;
-	unsigned long timeout;
+	unsigned long t;
 	void *buf = (void *)buffer;
 	size_t xtra;
-	volatile unsigned *done;
 
 	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
 	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
 	reinit_completion(&c->dma_done);
 	omap_start_dma(c->dma_channel);
 
-	timeout = jiffies + msecs_to_jiffies(20);
-	done = &c->dma_done.done;
-	while (time_before(jiffies, timeout))
-		if (*done)
-			break;
+	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
 
 	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
 
-	if (!*done) {
+	if (!t) {
 		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
 		goto out_copy;
 	}
@@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
 	return 0;
 }
 
-static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
+static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
 					 const unsigned char *buffer,
 					 int offset, size_t count)
 {
@@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	struct onenand_chip *this = mtd->priv;
 	dma_addr_t dma_src, dma_dst;
 	int bram_offset;
-	unsigned long timeout;
+	unsigned long t;
 	void *buf = (void *)buffer;
-	volatile unsigned *done;
 
 	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
 	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	reinit_completion(&c->dma_done);
 	omap_start_dma(c->dma_channel);
 
-	timeout = jiffies + msecs_to_jiffies(20);
-	done = &c->dma_done.done;
-	while (time_before(jiffies, timeout))
-		if (*done)
-			break;
+	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
 
 	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
 
-	if (!*done) {
+	if (!t) {
 		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
 		goto out_copy;
 	}
@@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	return 0;
 }
 
-#else
-
-static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
-					unsigned char *buffer, int offset,
-					size_t count)
-{
-	return -ENOSYS;
-}
-
-static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
-					 const unsigned char *buffer,
-					 int offset, size_t count)
-{
-	return -ENOSYS;
-}
-
-#endif
-
-#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
-
-static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
-					unsigned char *buffer, int offset,
-					size_t count)
-{
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-	struct onenand_chip *this = mtd->priv;
-	dma_addr_t dma_src, dma_dst;
-	int bram_offset;
-
-	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-	/* DMA is not used.  Revisit PM requirements before enabling it. */
-	if (1 || (c->dma_channel < 0) ||
-	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
-	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
-		memcpy(buffer, (__force void *)(this->base + bram_offset),
-		       count);
-		return 0;
-	}
-
-	dma_src = c->phys_base + bram_offset;
-	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
-				 DMA_FROM_DEVICE);
-	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
-		dev_err(&c->pdev->dev,
-			"Couldn't DMA map a %d byte buffer\n",
-			count);
-		return -1;
-	}
-
-	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
-				     count / 4, 1, 0, 0, 0);
-	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				dma_src, 0, 0);
-	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				 dma_dst, 0, 0);
-
-	reinit_completion(&c->dma_done);
-	omap_start_dma(c->dma_channel);
-	wait_for_completion(&c->dma_done);
-
-	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
-
-	return 0;
-}
-
-static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
-					 const unsigned char *buffer,
-					 int offset, size_t count)
-{
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-	struct onenand_chip *this = mtd->priv;
-	dma_addr_t dma_src, dma_dst;
-	int bram_offset;
-
-	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-	/* DMA is not used.  Revisit PM requirements before enabling it. */
-	if (1 || (c->dma_channel < 0) ||
-	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
-	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
-		memcpy((__force void *)(this->base + bram_offset), buffer,
-		       count);
-		return 0;
-	}
-
-	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
-				 DMA_TO_DEVICE);
-	dma_dst = c->phys_base + bram_offset;
-	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
-		dev_err(&c->pdev->dev,
-			"Couldn't DMA map a %d byte buffer\n",
-			count);
-		return -1;
-	}
-
-	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
-				     count / 2, 1, 0, 0, 0);
-	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				dma_src, 0, 0);
-	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				 dma_dst, 0, 0);
-
-	reinit_completion(&c->dma_done);
-	omap_start_dma(c->dma_channel);
-	wait_for_completion(&c->dma_done);
-
-	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
-
-	return 0;
-}
-
-#else
-
-static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
-					unsigned char *buffer, int offset,
-					size_t count)
-{
-	return -ENOSYS;
-}
-
-static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
-					 const unsigned char *buffer,
-					 int offset, size_t count)
-{
-	return -ENOSYS;
-}
-
-#endif
-
 static struct platform_driver omap2_onenand_driver;
 
 static void omap2_onenand_shutdown(struct platform_device *pdev)
@@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 	this = &c->onenand;
 	if (c->dma_channel >= 0) {
 		this->wait = omap2_onenand_wait;
-		if (c->flags & ONENAND_IN_OMAP34XX) {
-			this->read_bufferram = omap3_onenand_read_bufferram;
-			this->write_bufferram = omap3_onenand_write_bufferram;
-		} else {
-			this->read_bufferram = omap2_onenand_read_bufferram;
-			this->write_bufferram = omap2_onenand_write_bufferram;
-		}
+		this->read_bufferram = omap2_onenand_read_bufferram;
+		this->write_bufferram = omap2_onenand_write_bufferram;
 	}
 
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
-- 
2.11.0


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

[PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
Therefore replace open coded timeout waiting for completion in OMAP3
functions with API call and merge those two implementations.

Note that currently the is no single DMA user, so this change is basically
no-op. Those interested will have to find DMA configuration in the
linux-omap.git history.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v3: new patch

 drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
 1 file changed, 10 insertions(+), 155 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 883993bbe40b..5760e40be008 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
 	return 0;
 }
 
-#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
-
-static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
+static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
 					unsigned char *buffer, int offset,
 					size_t count)
 {
@@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
 	struct onenand_chip *this = mtd->priv;
 	dma_addr_t dma_src, dma_dst;
 	int bram_offset;
-	unsigned long timeout;
+	unsigned long t;
 	void *buf = (void *)buffer;
 	size_t xtra;
-	volatile unsigned *done;
 
 	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
 	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
 	reinit_completion(&c->dma_done);
 	omap_start_dma(c->dma_channel);
 
-	timeout = jiffies + msecs_to_jiffies(20);
-	done = &c->dma_done.done;
-	while (time_before(jiffies, timeout))
-		if (*done)
-			break;
+	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
 
 	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
 
-	if (!*done) {
+	if (!t) {
 		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
 		goto out_copy;
 	}
@@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
 	return 0;
 }
 
-static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
+static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
 					 const unsigned char *buffer,
 					 int offset, size_t count)
 {
@@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	struct onenand_chip *this = mtd->priv;
 	dma_addr_t dma_src, dma_dst;
 	int bram_offset;
-	unsigned long timeout;
+	unsigned long t;
 	void *buf = (void *)buffer;
-	volatile unsigned *done;
 
 	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
 	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
@@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	reinit_completion(&c->dma_done);
 	omap_start_dma(c->dma_channel);
 
-	timeout = jiffies + msecs_to_jiffies(20);
-	done = &c->dma_done.done;
-	while (time_before(jiffies, timeout))
-		if (*done)
-			break;
+	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
 
 	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
 
-	if (!*done) {
+	if (!t) {
 		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
 		goto out_copy;
 	}
@@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	return 0;
 }
 
-#else
-
-static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
-					unsigned char *buffer, int offset,
-					size_t count)
-{
-	return -ENOSYS;
-}
-
-static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
-					 const unsigned char *buffer,
-					 int offset, size_t count)
-{
-	return -ENOSYS;
-}
-
-#endif
-
-#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
-
-static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
-					unsigned char *buffer, int offset,
-					size_t count)
-{
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-	struct onenand_chip *this = mtd->priv;
-	dma_addr_t dma_src, dma_dst;
-	int bram_offset;
-
-	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-	/* DMA is not used.  Revisit PM requirements before enabling it. */
-	if (1 || (c->dma_channel < 0) ||
-	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
-	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
-		memcpy(buffer, (__force void *)(this->base + bram_offset),
-		       count);
-		return 0;
-	}
-
-	dma_src = c->phys_base + bram_offset;
-	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
-				 DMA_FROM_DEVICE);
-	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
-		dev_err(&c->pdev->dev,
-			"Couldn't DMA map a %d byte buffer\n",
-			count);
-		return -1;
-	}
-
-	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
-				     count / 4, 1, 0, 0, 0);
-	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				dma_src, 0, 0);
-	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				 dma_dst, 0, 0);
-
-	reinit_completion(&c->dma_done);
-	omap_start_dma(c->dma_channel);
-	wait_for_completion(&c->dma_done);
-
-	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
-
-	return 0;
-}
-
-static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
-					 const unsigned char *buffer,
-					 int offset, size_t count)
-{
-	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
-	struct onenand_chip *this = mtd->priv;
-	dma_addr_t dma_src, dma_dst;
-	int bram_offset;
-
-	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
-	/* DMA is not used.  Revisit PM requirements before enabling it. */
-	if (1 || (c->dma_channel < 0) ||
-	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
-	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
-		memcpy((__force void *)(this->base + bram_offset), buffer,
-		       count);
-		return 0;
-	}
-
-	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
-				 DMA_TO_DEVICE);
-	dma_dst = c->phys_base + bram_offset;
-	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
-		dev_err(&c->pdev->dev,
-			"Couldn't DMA map a %d byte buffer\n",
-			count);
-		return -1;
-	}
-
-	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
-				     count / 2, 1, 0, 0, 0);
-	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				dma_src, 0, 0);
-	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
-				 dma_dst, 0, 0);
-
-	reinit_completion(&c->dma_done);
-	omap_start_dma(c->dma_channel);
-	wait_for_completion(&c->dma_done);
-
-	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
-
-	return 0;
-}
-
-#else
-
-static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
-					unsigned char *buffer, int offset,
-					size_t count)
-{
-	return -ENOSYS;
-}
-
-static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
-					 const unsigned char *buffer,
-					 int offset, size_t count)
-{
-	return -ENOSYS;
-}
-
-#endif
-
 static struct platform_driver omap2_onenand_driver;
 
 static void omap2_onenand_shutdown(struct platform_device *pdev)
@@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 	this = &c->onenand;
 	if (c->dma_channel >= 0) {
 		this->wait = omap2_onenand_wait;
-		if (c->flags & ONENAND_IN_OMAP34XX) {
-			this->read_bufferram = omap3_onenand_read_bufferram;
-			this->write_bufferram = omap3_onenand_write_bufferram;
-		} else {
-			this->read_bufferram = omap2_onenand_read_bufferram;
-			this->write_bufferram = omap2_onenand_write_bufferram;
-		}
+		this->read_bufferram = omap2_onenand_read_bufferram;
+		this->write_bufferram = omap2_onenand_write_bufferram;
 	}
 
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
-- 
2.11.0

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Roger Quadros]

On 09/11/17 11:15, Ladislav Michl wrote:
> Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> Therefore replace open coded timeout waiting for completion in OMAP3
> functions with API call and merge those two implementations.
> 
> Note that currently the is no single DMA user, so this change is basically
> no-op. Those interested will have to find DMA configuration in the
> linux-omap.git history.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>

I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
be absolutely sure that we don't break DMA functionality if it ever worked.

Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
Tony?

> ---
>  Changes:
>  -v3: new patch
> 
>  drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
>  1 file changed, 10 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 883993bbe40b..5760e40be008 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
>  	return 0;
>  }
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  					unsigned char *buffer, int offset,
>  					size_t count)
>  {
> @@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
>  	size_t xtra;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  					 const unsigned char *buffer,
>  					 int offset, size_t count)
>  {
> @@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -#else
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
> -#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy(buffer, (__force void *)(this->base + bram_offset),
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = c->phys_base + bram_offset;
> -	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
> -				 DMA_FROM_DEVICE);
> -	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> -				     count / 4, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> -
> -	return 0;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy((__force void *)(this->base + bram_offset), buffer,
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
> -				 DMA_TO_DEVICE);
> -	dma_dst = c->phys_base + bram_offset;
> -	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
> -				     count / 2, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> -
> -	return 0;
> -}
> -
> -#else
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
>  static struct platform_driver omap2_onenand_driver;
>  
>  static void omap2_onenand_shutdown(struct platform_device *pdev)
> @@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  	this = &c->onenand;
>  	if (c->dma_channel >= 0) {
>  		this->wait = omap2_onenand_wait;
> -		if (c->flags & ONENAND_IN_OMAP34XX) {
> -			this->read_bufferram = omap3_onenand_read_bufferram;
> -			this->write_bufferram = omap3_onenand_write_bufferram;
> -		} else {
> -			this->read_bufferram = omap2_onenand_read_bufferram;
> -			this->write_bufferram = omap2_onenand_write_bufferram;
> -		}
> +		this->read_bufferram = omap2_onenand_read_bufferram;
> +		this->write_bufferram = omap2_onenand_write_bufferram;
>  	}
>  
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Roger Quadros]

On 09/11/17 11:15, Ladislav Michl wrote:
> Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> Therefore replace open coded timeout waiting for completion in OMAP3
> functions with API call and merge those two implementations.
> 
> Note that currently the is no single DMA user, so this change is basically
> no-op. Those interested will have to find DMA configuration in the
> linux-omap.git history.
> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>

I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
be absolutely sure that we don't break DMA functionality if it ever worked.

Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
Tony?

> ---
>  Changes:
>  -v3: new patch
> 
>  drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
>  1 file changed, 10 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 883993bbe40b..5760e40be008 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
>  	return 0;
>  }
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  					unsigned char *buffer, int offset,
>  					size_t count)
>  {
> @@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
>  	size_t xtra;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  					 const unsigned char *buffer,
>  					 int offset, size_t count)
>  {
> @@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -#else
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
> -#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy(buffer, (__force void *)(this->base + bram_offset),
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = c->phys_base + bram_offset;
> -	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
> -				 DMA_FROM_DEVICE);
> -	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> -				     count / 4, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> -
> -	return 0;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy((__force void *)(this->base + bram_offset), buffer,
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
> -				 DMA_TO_DEVICE);
> -	dma_dst = c->phys_base + bram_offset;
> -	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
> -				     count / 2, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> -
> -	return 0;
> -}
> -
> -#else
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
>  static struct platform_driver omap2_onenand_driver;
>  
>  static void omap2_onenand_shutdown(struct platform_device *pdev)
> @@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  	this = &c->onenand;
>  	if (c->dma_channel >= 0) {
>  		this->wait = omap2_onenand_wait;
> -		if (c->flags & ONENAND_IN_OMAP34XX) {
> -			this->read_bufferram = omap3_onenand_read_bufferram;
> -			this->write_bufferram = omap3_onenand_write_bufferram;
> -		} else {
> -			this->read_bufferram = omap2_onenand_read_bufferram;
> -			this->write_bufferram = omap2_onenand_write_bufferram;
> -		}
> +		this->read_bufferram = omap2_onenand_read_bufferram;
> +		this->write_bufferram = omap2_onenand_write_bufferram;
>  	}
>  
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> On 09/11/17 11:15, Ladislav Michl wrote:
> > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > Therefore replace open coded timeout waiting for completion in OMAP3
> > functions with API call and merge those two implementations.
> > 
> > Note that currently the is no single DMA user, so this change is basically
> > no-op. Those interested will have to find DMA configuration in the
> > linux-omap.git history.
> > 
> > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> 
> I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> be absolutely sure that we don't break DMA functionality if it ever worked.

It probably worked at least for OMAP3 as it was enabled in legacy kernels.

> Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> Tony?

I'll prepare next version patch serie for easier testing. Of course I would
prefer to be able to test changes myself, but I do not have any Nokias :-)

	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> On 09/11/17 11:15, Ladislav Michl wrote:
> > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > Therefore replace open coded timeout waiting for completion in OMAP3
> > functions with API call and merge those two implementations.
> > 
> > Note that currently the is no single DMA user, so this change is basically
> > no-op. Those interested will have to find DMA configuration in the
> > linux-omap.git history.
> > 
> > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> 
> I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> be absolutely sure that we don't break DMA functionality if it ever worked.

It probably worked at least for OMAP3 as it was enabled in legacy kernels.

> Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> Tony?

I'll prepare next version patch serie for easier testing. Of course I would
prefer to be able to test changes myself, but I do not have any Nokias :-)

	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 09:53]:
> On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> > On 09/11/17 11:15, Ladislav Michl wrote:
> > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > functions with API call and merge those two implementations.
> > > 
> > > Note that currently the is no single DMA user, so this change is basically
> > > no-op. Those interested will have to find DMA configuration in the
> > > linux-omap.git history.
> > > 
> > > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > 
> > I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> > be absolutely sure that we don't break DMA functionality if it ever worked.
> 
> It probably worked at least for OMAP3 as it was enabled in legacy kernels.
> 
> > Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> > Tony?
> 
> I'll prepare next version patch serie for easier testing. Of course I would
> prefer to be able to test changes myself, but I do not have any Nokias :-)

I tested Peter's dma changes yesterday and they worked. Yeah if you want
me to test something a complete series or a git branch makes it easier
for me to follow what all is needed.

Regards,

Tony

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 09:53]:
> On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> > On 09/11/17 11:15, Ladislav Michl wrote:
> > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > functions with API call and merge those two implementations.
> > > 
> > > Note that currently the is no single DMA user, so this change is basically
> > > no-op. Those interested will have to find DMA configuration in the
> > > linux-omap.git history.
> > > 
> > > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > 
> > I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> > be absolutely sure that we don't break DMA functionality if it ever worked.
> 
> It probably worked at least for OMAP3 as it was enabled in legacy kernels.
> 
> > Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> > Tony?
> 
> I'll prepare next version patch serie for easier testing. Of course I would
> prefer to be able to test changes myself, but I do not have any Nokias :-)

I tested Peter's dma changes yesterday and they worked. Yeah if you want
me to test something a complete series or a git branch makes it easier
for me to follow what all is needed.

Regards,

Tony

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 07:26:10AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171110 09:53]:
> > On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> > > On 09/11/17 11:15, Ladislav Michl wrote:
> > > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > > functions with API call and merge those two implementations.
> > > > 
> > > > Note that currently the is no single DMA user, so this change is basically
> > > > no-op. Those interested will have to find DMA configuration in the
> > > > linux-omap.git history.
> > > > 
> > > > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > > 
> > > I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> > > be absolutely sure that we don't break DMA functionality if it ever worked.
> > 
> > It probably worked at least for OMAP3 as it was enabled in legacy kernels.
> > 
> > > Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> > > Tony?
> > 
> > I'll prepare next version patch serie for easier testing. Of course I would
> > prefer to be able to test changes myself, but I do not have any Nokias :-)
> 
> I tested Peter's dma changes yesterday and they worked. Yeah if you want
> me to test something a complete series or a git branch makes it easier
> for me to follow what all is needed.

How did you configure DMA? Is there any additional patch?
So far I prepared complete patchset including Peter's changes, but I might
be good idea to start with something what's working for you.

Thanks,
	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 07:26:10AM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171110 09:53]:
> > On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> > > On 09/11/17 11:15, Ladislav Michl wrote:
> > > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > > functions with API call and merge those two implementations.
> > > > 
> > > > Note that currently the is no single DMA user, so this change is basically
> > > > no-op. Those interested will have to find DMA configuration in the
> > > > linux-omap.git history.
> > > > 
> > > > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > > 
> > > I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> > > be absolutely sure that we don't break DMA functionality if it ever worked.
> > 
> > It probably worked at least for OMAP3 as it was enabled in legacy kernels.
> > 
> > > Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> > > Tony?
> > 
> > I'll prepare next version patch serie for easier testing. Of course I would
> > prefer to be able to test changes myself, but I do not have any Nokias :-)
> 
> I tested Peter's dma changes yesterday and they worked. Yeah if you want
> me to test something a complete series or a git branch makes it easier
> for me to follow what all is needed.

How did you configure DMA? Is there any additional patch?
So far I prepared complete patchset including Peter's changes, but I might
be good idea to start with something what's working for you.

Thanks,
	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 18:21]:
> On Fri, Nov 10, 2017 at 07:26:10AM -0800, Tony Lindgren wrote:
> > * Ladislav Michl <ladis@linux-mips.org> [171110 09:53]:
> > > On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> > > > On 09/11/17 11:15, Ladislav Michl wrote:
> > > > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > > > functions with API call and merge those two implementations.
> > > > > 
> > > > > Note that currently the is no single DMA user, so this change is basically
> > > > > no-op. Those interested will have to find DMA configuration in the
> > > > > linux-omap.git history.
> > > > > 
> > > > > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > > > 
> > > > I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> > > > be absolutely sure that we don't break DMA functionality if it ever worked.
> > > 
> > > It probably worked at least for OMAP3 as it was enabled in legacy kernels.
> > > 
> > > > Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> > > > Tony?
> > > 
> > > I'll prepare next version patch serie for easier testing. Of course I would
> > > prefer to be able to test changes myself, but I do not have any Nokias :-)
> > 
> > I tested Peter's dma changes yesterday and they worked. Yeah if you want
> > me to test something a complete series or a git branch makes it easier
> > for me to follow what all is needed.
> 
> How did you configure DMA? Is there any additional patch?
> So far I prepared complete patchset including Peter's changes, but I might
> be good idea to start with something what's working for you.

I just made sure things keep working with Peter's changes, no additional
patches. So the dma is barely used at all.

Regards,

Tony

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 18:21]:
> On Fri, Nov 10, 2017 at 07:26:10AM -0800, Tony Lindgren wrote:
> > * Ladislav Michl <ladis@linux-mips.org> [171110 09:53]:
> > > On Fri, Nov 10, 2017 at 10:21:51AM +0200, Roger Quadros wrote:
> > > > On 09/11/17 11:15, Ladislav Michl wrote:
> > > > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > > > functions with API call and merge those two implementations.
> > > > > 
> > > > > Note that currently the is no single DMA user, so this change is basically
> > > > > no-op. Those interested will have to find DMA configuration in the
> > > > > linux-omap.git history.
> > > > > 
> > > > > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > > > 
> > > > I'll be happy if there are no OMAP2 vs OMAP3 differences in code but we need to
> > > > be absolutely sure that we don't break DMA functionality if it ever worked.
> > > 
> > > It probably worked at least for OMAP3 as it was enabled in legacy kernels.
> > > 
> > > > Can we somehow test OneNAND DMA on OMAP2 and OMAP3?
> > > > Tony?
> > > 
> > > I'll prepare next version patch serie for easier testing. Of course I would
> > > prefer to be able to test changes myself, but I do not have any Nokias :-)
> > 
> > I tested Peter's dma changes yesterday and they worked. Yeah if you want
> > me to test something a complete series or a git branch makes it easier
> > for me to follow what all is needed.
> 
> How did you configure DMA? Is there any additional patch?
> So far I prepared complete patchset including Peter's changes, but I might
> be good idea to start with something what's working for you.

I just made sure things keep working with Peter's changes, no additional
patches. So the dma is barely used at all.

Regards,

Tony

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
> I just made sure things keep working with Peter's changes, no additional
> patches. So the dma is barely used at all.

It seemed suspicious to me looking here:
https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
as wait_for_completion_timeout is returning time remaining and zero on
timeout :-)
Fixed in next version and also changed to wait_for_completion_io_timeout
to get proper sched stats.
Btw, I think we should stop DMA on timeout as we are unmapping DMA region
later and it might not behave nicely if we do so while DMA is eventually
running (that's fixed too).

I made Peter's patches part of next version and enabled DMA unconditionally.
It works nicely on:
OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
...
omap-gpmc 6e000000.gpmc: GPMC revision 5.0
gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
OneNAND version = 0x0031
Scanning device for bad blocks
OneNAND eraseblock 597 is an initial bad block
OneNAND eraseblock 1159 is an initial bad block
OneNAND eraseblock 2812 is an initial bad block
omap2-onenand 30000000.onenand: optimized timings for 83 MHz
2 ofpart partitions found on MTD device 30000000.onenand
Creating 2 MTD partitions on "30000000.onenand":
0x000000000000-0x000000080000 : "SPL"
0x000000080000-0x000020000000 : "UBI"
...

Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
default. We are brave enough and want some testing, right?
It would be nice if someone could provide some benchmarks using PIO
and DMA mode. I do not expect any dramatic change, but kernel latencies
should decrease when doing flash I/O.

Based on above I also think R/B pin should be in ordinary GPIO mode.
Perhaps using external DMA request is somehow posible, but it is not clear
to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
so I'll happily leave it for others.

Btw, using R/B pin would elimitate latencies caused by busy looping while
waiting for onenand command to complete. Nice todo for someone with a lot
of spare time :-)

Best regards,
	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
> I just made sure things keep working with Peter's changes, no additional
> patches. So the dma is barely used at all.

It seemed suspicious to me looking here:
https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
as wait_for_completion_timeout is returning time remaining and zero on
timeout :-)
Fixed in next version and also changed to wait_for_completion_io_timeout
to get proper sched stats.
Btw, I think we should stop DMA on timeout as we are unmapping DMA region
later and it might not behave nicely if we do so while DMA is eventually
running (that's fixed too).

I made Peter's patches part of next version and enabled DMA unconditionally.
It works nicely on:
OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
...
omap-gpmc 6e000000.gpmc: GPMC revision 5.0
gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
OneNAND version = 0x0031
Scanning device for bad blocks
OneNAND eraseblock 597 is an initial bad block
OneNAND eraseblock 1159 is an initial bad block
OneNAND eraseblock 2812 is an initial bad block
omap2-onenand 30000000.onenand: optimized timings for 83 MHz
2 ofpart partitions found on MTD device 30000000.onenand
Creating 2 MTD partitions on "30000000.onenand":
0x000000000000-0x000000080000 : "SPL"
0x000000080000-0x000020000000 : "UBI"
...

Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
default. We are brave enough and want some testing, right?
It would be nice if someone could provide some benchmarks using PIO
and DMA mode. I do not expect any dramatic change, but kernel latencies
should decrease when doing flash I/O.

Based on above I also think R/B pin should be in ordinary GPIO mode.
Perhaps using external DMA request is somehow posible, but it is not clear
to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
so I'll happily leave it for others.

Btw, using R/B pin would elimitate latencies caused by busy looping while
waiting for onenand command to complete. Nice todo for someone with a lot
of spare time :-)

Best regards,
	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 11/11/2017 02:50 PM, Ladislav Michl wrote:
> On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
>> I just made sure things keep working with Peter's changes, no additional
>> patches. So the dma is barely used at all.
> 
> It seemed suspicious to me looking here:
> https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
> as wait_for_completion_timeout is returning time remaining and zero on
> timeout :-)

aargh, yes, you are right...

> Fixed in next version and also changed to wait_for_completion_io_timeout
> to get proper sched stats.
> Btw, I think we should stop DMA on timeout as we are unmapping DMA region
> later and it might not behave nicely if we do so while DMA is eventually
> running (that's fixed too).
> 
> I made Peter's patches part of next version and enabled DMA unconditionally.
> It works nicely on:

Pretty cool! Thanks for doing it!

> OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
> OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> ...
> omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
> Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> OneNAND version = 0x0031
> Scanning device for bad blocks
> OneNAND eraseblock 597 is an initial bad block
> OneNAND eraseblock 1159 is an initial bad block
> OneNAND eraseblock 2812 is an initial bad block
> omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> 2 ofpart partitions found on MTD device 30000000.onenand
> Creating 2 MTD partitions on "30000000.onenand":
> 0x000000000000-0x000000080000 : "SPL"
> 0x000000080000-0x000020000000 : "UBI"
> ...
> 
> Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
> default. We are brave enough and want some testing, right?
> It would be nice if someone could provide some benchmarks using PIO
> and DMA mode. I do not expect any dramatic change, but kernel latencies
> should decrease when doing flash I/O.
> 
> Based on above I also think R/B pin should be in ordinary GPIO mode.
> Perhaps using external DMA request is somehow posible, but it is not clear
> to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
> so I'll happily leave it for others.
> 
> Btw, using R/B pin would elimitate latencies caused by busy looping while
> waiting for onenand command to complete. Nice todo for someone with a lot
> of spare time :-)
> 
> Best regards,
> 	ladis
> 


-- 
Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 11/11/2017 02:50 PM, Ladislav Michl wrote:
> On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
>> I just made sure things keep working with Peter's changes, no additional
>> patches. So the dma is barely used at all.
> 
> It seemed suspicious to me looking here:
> https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
> as wait_for_completion_timeout is returning time remaining and zero on
> timeout :-)

aargh, yes, you are right...

> Fixed in next version and also changed to wait_for_completion_io_timeout
> to get proper sched stats.
> Btw, I think we should stop DMA on timeout as we are unmapping DMA region
> later and it might not behave nicely if we do so while DMA is eventually
> running (that's fixed too).
> 
> I made Peter's patches part of next version and enabled DMA unconditionally.
> It works nicely on:

Pretty cool! Thanks for doing it!

> OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
> OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> ...
> omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
> Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> OneNAND version = 0x0031
> Scanning device for bad blocks
> OneNAND eraseblock 597 is an initial bad block
> OneNAND eraseblock 1159 is an initial bad block
> OneNAND eraseblock 2812 is an initial bad block
> omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> 2 ofpart partitions found on MTD device 30000000.onenand
> Creating 2 MTD partitions on "30000000.onenand":
> 0x000000000000-0x000000080000 : "SPL"
> 0x000000080000-0x000020000000 : "UBI"
> ...
> 
> Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
> default. We are brave enough and want some testing, right?
> It would be nice if someone could provide some benchmarks using PIO
> and DMA mode. I do not expect any dramatic change, but kernel latencies
> should decrease when doing flash I/O.
> 
> Based on above I also think R/B pin should be in ordinary GPIO mode.
> Perhaps using external DMA request is somehow posible, but it is not clear
> to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
> so I'll happily leave it for others.
> 
> Btw, using R/B pin would elimitate latencies caused by busy looping while
> waiting for onenand command to complete. Nice todo for someone with a lot
> of spare time :-)
> 
> Best regards,
> 	ladis
> 


-- 
Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Roger Quadros]

On 11/11/17 14:50, Ladislav Michl wrote:
> On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
>> I just made sure things keep working with Peter's changes, no additional
>> patches. So the dma is barely used at all.
> 
> It seemed suspicious to me looking here:
> https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
> as wait_for_completion_timeout is returning time remaining and zero on
> timeout :-)
> Fixed in next version and also changed to wait_for_completion_io_timeout
> to get proper sched stats.
> Btw, I think we should stop DMA on timeout as we are unmapping DMA region
> later and it might not behave nicely if we do so while DMA is eventually
> running (that's fixed too).
> 
> I made Peter's patches part of next version and enabled DMA unconditionally.

That's cool, but I'd still hold from making it default in first go.
It could have more testing and benchmarking.

> It works nicely on:
> OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
> OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> ...
> omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
> Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> OneNAND version = 0x0031
> Scanning device for bad blocks
> OneNAND eraseblock 597 is an initial bad block
> OneNAND eraseblock 1159 is an initial bad block
> OneNAND eraseblock 2812 is an initial bad block
> omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> 2 ofpart partitions found on MTD device 30000000.onenand
> Creating 2 MTD partitions on "30000000.onenand":
> 0x000000000000-0x000000080000 : "SPL"
> 0x000000080000-0x000020000000 : "UBI"
> ...
> 
> Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
> default. We are brave enough and want some testing, right?
> It would be nice if someone could provide some benchmarks using PIO
> and DMA mode. I do not expect any dramatic change, but kernel latencies
> should decrease when doing flash I/O.

There should be noticeable difference between both when the CPU is loaded.

> 
> Based on above I also think R/B pin should be in ordinary GPIO mode.
> Perhaps using external DMA request is somehow posible, but it is not clear
> to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
> so I'll happily leave it for others.

At least on NAND we use R/B as a plain GPIO that is polled till it shows
ready during NAND erase/program cycles.
e.g. see nand_wait() in nand/nand_base.c
and omap_dev_ready() in nand/omap2.c

So ready checking could be done similarly in onenand core?

> 
> Btw, using R/B pin would elimitate latencies caused by busy looping while
> waiting for onenand command to complete. Nice todo for someone with a lot
> of spare time :-)
> 
> Best regards,
> 	ladis
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Roger Quadros]

On 11/11/17 14:50, Ladislav Michl wrote:
> On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
>> I just made sure things keep working with Peter's changes, no additional
>> patches. So the dma is barely used at all.
> 
> It seemed suspicious to me looking here:
> https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
> as wait_for_completion_timeout is returning time remaining and zero on
> timeout :-)
> Fixed in next version and also changed to wait_for_completion_io_timeout
> to get proper sched stats.
> Btw, I think we should stop DMA on timeout as we are unmapping DMA region
> later and it might not behave nicely if we do so while DMA is eventually
> running (that's fixed too).
> 
> I made Peter's patches part of next version and enabled DMA unconditionally.

That's cool, but I'd still hold from making it default in first go.
It could have more testing and benchmarking.

> It works nicely on:
> OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
> OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> ...
> omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
> Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> OneNAND version = 0x0031
> Scanning device for bad blocks
> OneNAND eraseblock 597 is an initial bad block
> OneNAND eraseblock 1159 is an initial bad block
> OneNAND eraseblock 2812 is an initial bad block
> omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> 2 ofpart partitions found on MTD device 30000000.onenand
> Creating 2 MTD partitions on "30000000.onenand":
> 0x000000000000-0x000000080000 : "SPL"
> 0x000000080000-0x000020000000 : "UBI"
> ...
> 
> Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
> default. We are brave enough and want some testing, right?
> It would be nice if someone could provide some benchmarks using PIO
> and DMA mode. I do not expect any dramatic change, but kernel latencies
> should decrease when doing flash I/O.

There should be noticeable difference between both when the CPU is loaded.

> 
> Based on above I also think R/B pin should be in ordinary GPIO mode.
> Perhaps using external DMA request is somehow posible, but it is not clear
> to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
> so I'll happily leave it for others.

At least on NAND we use R/B as a plain GPIO that is polled till it shows
ready during NAND erase/program cycles.
e.g. see nand_wait() in nand/nand_base.c
and omap_dev_ready() in nand/omap2.c

So ready checking could be done similarly in onenand core?

> 
> Btw, using R/B pin would elimitate latencies caused by busy looping while
> waiting for onenand command to complete. Nice todo for someone with a lot
> of spare time :-)
> 
> Best regards,
> 	ladis
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Tue, Nov 14, 2017 at 04:47:46PM +0200, Roger Quadros wrote:
> On 11/11/17 14:50, Ladislav Michl wrote:
> > On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
> >> I just made sure things keep working with Peter's changes, no additional
> >> patches. So the dma is barely used at all.
> > 
> > It seemed suspicious to me looking here:
> > https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
> > as wait_for_completion_timeout is returning time remaining and zero on
> > timeout :-)
> > Fixed in next version and also changed to wait_for_completion_io_timeout
> > to get proper sched stats.
> > Btw, I think we should stop DMA on timeout as we are unmapping DMA region
> > later and it might not behave nicely if we do so while DMA is eventually
> > running (that's fixed too).
> > 
> > I made Peter's patches part of next version and enabled DMA unconditionally.
> 
> That's cool, but I'd still hold from making it default in first go.
> It could have more testing and benchmarking.

I do not expect v4 to be the last version of patchset and I enabled it to
get as much testing as possible.

> > It works nicely on:
> > OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
> > OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> > ...
> > omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> > gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> > omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
> > Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> > OneNAND version = 0x0031
> > Scanning device for bad blocks
> > OneNAND eraseblock 597 is an initial bad block
> > OneNAND eraseblock 1159 is an initial bad block
> > OneNAND eraseblock 2812 is an initial bad block
> > omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> > 2 ofpart partitions found on MTD device 30000000.onenand
> > Creating 2 MTD partitions on "30000000.onenand":
> > 0x000000000000-0x000000080000 : "SPL"
> > 0x000000080000-0x000020000000 : "UBI"
> > ...
> > 
> > Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
> > default. We are brave enough and want some testing, right?
> > It would be nice if someone could provide some benchmarks using PIO
> > and DMA mode. I do not expect any dramatic change, but kernel latencies
> > should decrease when doing flash I/O.
> 
> There should be noticeable difference between both when the CPU is loaded.
> 
> > 
> > Based on above I also think R/B pin should be in ordinary GPIO mode.
> > Perhaps using external DMA request is somehow posible, but it is not clear
> > to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
> > so I'll happily leave it for others.
> 
> At least on NAND we use R/B as a plain GPIO that is polled till it shows
> ready during NAND erase/program cycles.
> e.g. see nand_wait() in nand/nand_base.c
> and omap_dev_ready() in nand/omap2.c

As answered previously, OneNAND R/B pin is indeed used the same (*) way, it is
just done at OMAP2+ driver level rather than in OneNAND base driver.

(*) it is actually a bit better as R/B is configured as interrupt source and
we are just waiting for completion.

> So ready checking could be done similarly in onenand core?

Yes, but that could wait for another round of driver updates. I'd like to
sort GPMC interface first.

There's more to be moved to OneNAND base driver (chip frequency probing,
latency settings, etc).

> > 
> > Btw, using R/B pin would elimitate latencies caused by busy looping while
> > waiting for onenand command to complete. Nice todo for someone with a lot
> > of spare time :-)
> > 
> > Best regards,
> > 	ladis
> > 
> 
> -- 
> cheers,
> -roger
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Tue, Nov 14, 2017 at 04:47:46PM +0200, Roger Quadros wrote:
> On 11/11/17 14:50, Ladislav Michl wrote:
> > On Fri, Nov 10, 2017 at 10:29:38AM -0800, Tony Lindgren wrote:
> >> I just made sure things keep working with Peter's changes, no additional
> >> patches. So the dma is barely used at all.
> > 
> > It seemed suspicious to me looking here:
> > https://github.com/omap-audio/linux-audio/commit/52e914395afe31a7401b35814b6dabf3ef46a052#diff-1662a4cc544d322b68c547cfdc99448cR312
> > as wait_for_completion_timeout is returning time remaining and zero on
> > timeout :-)
> > Fixed in next version and also changed to wait_for_completion_io_timeout
> > to get proper sched stats.
> > Btw, I think we should stop DMA on timeout as we are unmapping DMA region
> > later and it might not behave nicely if we do so while DMA is eventually
> > running (that's fixed too).
> > 
> > I made Peter's patches part of next version and enabled DMA unconditionally.
> 
> That's cool, but I'd still hold from making it default in first go.
> It could have more testing and benchmarking.

I do not expect v4 to be the last version of patchset and I enabled it to
get as much testing as possible.

> > It works nicely on:
> > OF: fdt: Machine model: IGEPv2 Rev. C (TI OMAP AM/DM37x)
> > OMAP3630/DM3730 ES1.2 (l2cache iva sgx neon isp 192mhz_clk)
> > ...
> > omap-gpmc 6e000000.gpmc: GPMC revision 5.0
> > gpmc_mem_init: disabling cs 0 mapped at 0x0-0x1000000
> > omap2-onenand 30000000.onenand: initializing on CS0 (0x30000000), va e0080000, DMA mode
> > Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58)
> > OneNAND version = 0x0031
> > Scanning device for bad blocks
> > OneNAND eraseblock 597 is an initial bad block
> > OneNAND eraseblock 1159 is an initial bad block
> > OneNAND eraseblock 2812 is an initial bad block
> > omap2-onenand 30000000.onenand: optimized timings for 83 MHz
> > 2 ofpart partitions found on MTD device 30000000.onenand
> > Creating 2 MTD partitions on "30000000.onenand":
> > 0x000000000000-0x000000080000 : "SPL"
> > 0x000000080000-0x000020000000 : "UBI"
> > ...
> > 
> > Based on this experiment, I'll delay v4 a bit and leave DMA enabled by
> > default. We are brave enough and want some testing, right?
> > It would be nice if someone could provide some benchmarks using PIO
> > and DMA mode. I do not expect any dramatic change, but kernel latencies
> > should decrease when doing flash I/O.
> 
> There should be noticeable difference between both when the CPU is loaded.
> 
> > 
> > Based on above I also think R/B pin should be in ordinary GPIO mode.
> > Perhaps using external DMA request is somehow posible, but it is not clear
> > to me how after yet another reading of SDMA, GPMC and OneNAND documentation,
> > so I'll happily leave it for others.
> 
> At least on NAND we use R/B as a plain GPIO that is polled till it shows
> ready during NAND erase/program cycles.
> e.g. see nand_wait() in nand/nand_base.c
> and omap_dev_ready() in nand/omap2.c

As answered previously, OneNAND R/B pin is indeed used the same (*) way, it is
just done at OMAP2+ driver level rather than in OneNAND base driver.

(*) it is actually a bit better as R/B is configured as interrupt source and
we are just waiting for completion.

> So ready checking could be done similarly in onenand core?

Yes, but that could wait for another round of driver updates. I'd like to
sort GPMC interface first.

There's more to be moved to OneNAND base driver (chip frequency probing,
latency settings, etc).

> > 
> > Btw, using R/B pin would elimitate latencies caused by busy looping while
> > waiting for onenand command to complete. Nice todo for someone with a lot
> > of spare time :-)
> > 
> > Best regards,
> > 	ladis
> > 
> 
> -- 
> cheers,
> -roger
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]

Hi,

On 2017-11-09 11:15, Ladislav Michl wrote:
> Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> Therefore replace open coded timeout waiting for completion in OMAP3
> functions with API call and merge those two implementations.
> 
> Note that currently the is no single DMA user, so this change is basically
> no-op. Those interested will have to find DMA configuration in the
> linux-omap.git history.

fwiw I have two patches for some time to convert the omap2 onenand
driver to DMAengine:
https://github.com/omap-audio/linux-audio/commits/peter/linux-next-wip/drivers/mtd/onenand/omap2.c

I can wait for your series and rebase mine or if you have time can test
them and see if they can be included in your update series.

- Péter

> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v3: new patch
> 
>  drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
>  1 file changed, 10 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 883993bbe40b..5760e40be008 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
>  	return 0;
>  }
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  					unsigned char *buffer, int offset,
>  					size_t count)
>  {
> @@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
>  	size_t xtra;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  					 const unsigned char *buffer,
>  					 int offset, size_t count)
>  {
> @@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -#else
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
> -#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy(buffer, (__force void *)(this->base + bram_offset),
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = c->phys_base + bram_offset;
> -	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
> -				 DMA_FROM_DEVICE);
> -	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> -				     count / 4, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> -
> -	return 0;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy((__force void *)(this->base + bram_offset), buffer,
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
> -				 DMA_TO_DEVICE);
> -	dma_dst = c->phys_base + bram_offset;
> -	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
> -				     count / 2, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> -
> -	return 0;
> -}
> -
> -#else
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
>  static struct platform_driver omap2_onenand_driver;
>  
>  static void omap2_onenand_shutdown(struct platform_device *pdev)
> @@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  	this = &c->onenand;
>  	if (c->dma_channel >= 0) {
>  		this->wait = omap2_onenand_wait;
> -		if (c->flags & ONENAND_IN_OMAP34XX) {
> -			this->read_bufferram = omap3_onenand_read_bufferram;
> -			this->write_bufferram = omap3_onenand_write_bufferram;
> -		} else {
> -			this->read_bufferram = omap2_onenand_read_bufferram;
> -			this->write_bufferram = omap2_onenand_write_bufferram;
> -		}
> +		this->read_bufferram = omap2_onenand_read_bufferram;
> +		this->write_bufferram = omap2_onenand_write_bufferram;
>  	}
>  
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> 

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]

Hi,

On 2017-11-09 11:15, Ladislav Michl wrote:
> Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> Therefore replace open coded timeout waiting for completion in OMAP3
> functions with API call and merge those two implementations.
> 
> Note that currently the is no single DMA user, so this change is basically
> no-op. Those interested will have to find DMA configuration in the
> linux-omap.git history.

fwiw I have two patches for some time to convert the omap2 onenand
driver to DMAengine:
https://github.com/omap-audio/linux-audio/commits/peter/linux-next-wip/drivers/mtd/onenand/omap2.c

I can wait for your series and rebase mine or if you have time can test
them and see if they can be included in your update series.

- Péter

> 
> Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> ---
>  Changes:
>  -v3: new patch
> 
>  drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
>  1 file changed, 10 insertions(+), 155 deletions(-)
> 
> diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> index 883993bbe40b..5760e40be008 100644
> --- a/drivers/mtd/onenand/omap2.c
> +++ b/drivers/mtd/onenand/omap2.c
> @@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
>  	return 0;
>  }
>  
> -#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  					unsigned char *buffer, int offset,
>  					size_t count)
>  {
> @@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
>  	size_t xtra;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> +static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  					 const unsigned char *buffer,
>  					 int offset, size_t count)
>  {
> @@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	struct onenand_chip *this = mtd->priv;
>  	dma_addr_t dma_src, dma_dst;
>  	int bram_offset;
> -	unsigned long timeout;
> +	unsigned long t;
>  	void *buf = (void *)buffer;
> -	volatile unsigned *done;
>  
>  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
>  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> @@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	reinit_completion(&c->dma_done);
>  	omap_start_dma(c->dma_channel);
>  
> -	timeout = jiffies + msecs_to_jiffies(20);
> -	done = &c->dma_done.done;
> -	while (time_before(jiffies, timeout))
> -		if (*done)
> -			break;
> +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
>  
>  	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
>  
> -	if (!*done) {
> +	if (!t) {
>  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
>  		goto out_copy;
>  	}
> @@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
>  	return 0;
>  }
>  
> -#else
> -
> -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
> -#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy(buffer, (__force void *)(this->base + bram_offset),
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = c->phys_base + bram_offset;
> -	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
> -				 DMA_FROM_DEVICE);
> -	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> -				     count / 4, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> -
> -	return 0;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> -	struct onenand_chip *this = mtd->priv;
> -	dma_addr_t dma_src, dma_dst;
> -	int bram_offset;
> -
> -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> -	if (1 || (c->dma_channel < 0) ||
> -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> -		memcpy((__force void *)(this->base + bram_offset), buffer,
> -		       count);
> -		return 0;
> -	}
> -
> -	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
> -				 DMA_TO_DEVICE);
> -	dma_dst = c->phys_base + bram_offset;
> -	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
> -		dev_err(&c->pdev->dev,
> -			"Couldn't DMA map a %d byte buffer\n",
> -			count);
> -		return -1;
> -	}
> -
> -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
> -				     count / 2, 1, 0, 0, 0);
> -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				dma_src, 0, 0);
> -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> -				 dma_dst, 0, 0);
> -
> -	reinit_completion(&c->dma_done);
> -	omap_start_dma(c->dma_channel);
> -	wait_for_completion(&c->dma_done);
> -
> -	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> -
> -	return 0;
> -}
> -
> -#else
> -
> -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> -					unsigned char *buffer, int offset,
> -					size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> -					 const unsigned char *buffer,
> -					 int offset, size_t count)
> -{
> -	return -ENOSYS;
> -}
> -
> -#endif
> -
>  static struct platform_driver omap2_onenand_driver;
>  
>  static void omap2_onenand_shutdown(struct platform_device *pdev)
> @@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
>  	this = &c->onenand;
>  	if (c->dma_channel >= 0) {
>  		this->wait = omap2_onenand_wait;
> -		if (c->flags & ONENAND_IN_OMAP34XX) {
> -			this->read_bufferram = omap3_onenand_read_bufferram;
> -			this->write_bufferram = omap3_onenand_write_bufferram;
> -		} else {
> -			this->read_bufferram = omap2_onenand_read_bufferram;
> -			this->write_bufferram = omap2_onenand_write_bufferram;
> -		}
> +		this->read_bufferram = omap2_onenand_read_bufferram;
> +		this->write_bufferram = omap2_onenand_write_bufferram;
>  	}
>  
>  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> 

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:25:24AM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> On 2017-11-09 11:15, Ladislav Michl wrote:
> > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > Therefore replace open coded timeout waiting for completion in OMAP3
> > functions with API call and merge those two implementations.
> > 
> > Note that currently the is no single DMA user, so this change is basically
> > no-op. Those interested will have to find DMA configuration in the
> > linux-omap.git history.
> 
> fwiw I have two patches for some time to convert the omap2 onenand
> driver to DMAengine:
> https://github.com/omap-audio/linux-audio/commits/peter/linux-next-wip/drivers/mtd/onenand/omap2.c

That is incredible! I was thinking about it as a next step and you already
did all the work.

> I can wait for your series and rebase mine or if you have time can test
> them and see if they can be included in your update series.

I run out of time few days ago already, but this looks so good that it is
worth to delay other work. I'll include it in next version of patch serie.

Also it will allow us to dump 'dma-channel' and use DMA if gpio pin
is configured which was intended logic of original driver. 'dma-channel'
was introduced during mechanical conversion to DT and fortunately it is
not used yet, so we can safely remove it again.

Thanks,
	ladis

> - Péter
> 
> > 
> > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > ---
> >  Changes:
> >  -v3: new patch
> > 
> >  drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
> >  1 file changed, 10 insertions(+), 155 deletions(-)
> > 
> > diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> > index 883993bbe40b..5760e40be008 100644
> > --- a/drivers/mtd/onenand/omap2.c
> > +++ b/drivers/mtd/onenand/omap2.c
> > @@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
> >  	return 0;
> >  }
> >  
> > -#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
> > -
> > -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > +static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  					unsigned char *buffer, int offset,
> >  					size_t count)
> >  {
> > @@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  	struct onenand_chip *this = mtd->priv;
> >  	dma_addr_t dma_src, dma_dst;
> >  	int bram_offset;
> > -	unsigned long timeout;
> > +	unsigned long t;
> >  	void *buf = (void *)buffer;
> >  	size_t xtra;
> > -	volatile unsigned *done;
> >  
> >  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> >  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  	reinit_completion(&c->dma_done);
> >  	omap_start_dma(c->dma_channel);
> >  
> > -	timeout = jiffies + msecs_to_jiffies(20);
> > -	done = &c->dma_done.done;
> > -	while (time_before(jiffies, timeout))
> > -		if (*done)
> > -			break;
> > +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
> >  
> >  	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> >  
> > -	if (!*done) {
> > +	if (!t) {
> >  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
> >  		goto out_copy;
> >  	}
> > @@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  	return 0;
> >  }
> >  
> > -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > +static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  					 const unsigned char *buffer,
> >  					 int offset, size_t count)
> >  {
> > @@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  	struct onenand_chip *this = mtd->priv;
> >  	dma_addr_t dma_src, dma_dst;
> >  	int bram_offset;
> > -	unsigned long timeout;
> > +	unsigned long t;
> >  	void *buf = (void *)buffer;
> > -	volatile unsigned *done;
> >  
> >  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> >  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  	reinit_completion(&c->dma_done);
> >  	omap_start_dma(c->dma_channel);
> >  
> > -	timeout = jiffies + msecs_to_jiffies(20);
> > -	done = &c->dma_done.done;
> > -	while (time_before(jiffies, timeout))
> > -		if (*done)
> > -			break;
> > +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
> >  
> >  	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> >  
> > -	if (!*done) {
> > +	if (!t) {
> >  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
> >  		goto out_copy;
> >  	}
> > @@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  	return 0;
> >  }
> >  
> > -#else
> > -
> > -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > -					unsigned char *buffer, int offset,
> > -					size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > -					 const unsigned char *buffer,
> > -					 int offset, size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -#endif
> > -
> > -#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
> > -
> > -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > -					unsigned char *buffer, int offset,
> > -					size_t count)
> > -{
> > -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > -	struct onenand_chip *this = mtd->priv;
> > -	dma_addr_t dma_src, dma_dst;
> > -	int bram_offset;
> > -
> > -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> > -	if (1 || (c->dma_channel < 0) ||
> > -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> > -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> > -		memcpy(buffer, (__force void *)(this->base + bram_offset),
> > -		       count);
> > -		return 0;
> > -	}
> > -
> > -	dma_src = c->phys_base + bram_offset;
> > -	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
> > -				 DMA_FROM_DEVICE);
> > -	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
> > -		dev_err(&c->pdev->dev,
> > -			"Couldn't DMA map a %d byte buffer\n",
> > -			count);
> > -		return -1;
> > -	}
> > -
> > -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> > -				     count / 4, 1, 0, 0, 0);
> > -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				dma_src, 0, 0);
> > -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				 dma_dst, 0, 0);
> > -
> > -	reinit_completion(&c->dma_done);
> > -	omap_start_dma(c->dma_channel);
> > -	wait_for_completion(&c->dma_done);
> > -
> > -	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> > -
> > -	return 0;
> > -}
> > -
> > -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > -					 const unsigned char *buffer,
> > -					 int offset, size_t count)
> > -{
> > -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > -	struct onenand_chip *this = mtd->priv;
> > -	dma_addr_t dma_src, dma_dst;
> > -	int bram_offset;
> > -
> > -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> > -	if (1 || (c->dma_channel < 0) ||
> > -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> > -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> > -		memcpy((__force void *)(this->base + bram_offset), buffer,
> > -		       count);
> > -		return 0;
> > -	}
> > -
> > -	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
> > -				 DMA_TO_DEVICE);
> > -	dma_dst = c->phys_base + bram_offset;
> > -	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
> > -		dev_err(&c->pdev->dev,
> > -			"Couldn't DMA map a %d byte buffer\n",
> > -			count);
> > -		return -1;
> > -	}
> > -
> > -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
> > -				     count / 2, 1, 0, 0, 0);
> > -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				dma_src, 0, 0);
> > -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				 dma_dst, 0, 0);
> > -
> > -	reinit_completion(&c->dma_done);
> > -	omap_start_dma(c->dma_channel);
> > -	wait_for_completion(&c->dma_done);
> > -
> > -	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> > -
> > -	return 0;
> > -}
> > -
> > -#else
> > -
> > -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > -					unsigned char *buffer, int offset,
> > -					size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > -					 const unsigned char *buffer,
> > -					 int offset, size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -#endif
> > -
> >  static struct platform_driver omap2_onenand_driver;
> >  
> >  static void omap2_onenand_shutdown(struct platform_device *pdev)
> > @@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
> >  	this = &c->onenand;
> >  	if (c->dma_channel >= 0) {
> >  		this->wait = omap2_onenand_wait;
> > -		if (c->flags & ONENAND_IN_OMAP34XX) {
> > -			this->read_bufferram = omap3_onenand_read_bufferram;
> > -			this->write_bufferram = omap3_onenand_write_bufferram;
> > -		} else {
> > -			this->read_bufferram = omap2_onenand_read_bufferram;
> > -			this->write_bufferram = omap2_onenand_write_bufferram;
> > -		}
> > +		this->read_bufferram = omap2_onenand_read_bufferram;
> > +		this->write_bufferram = omap2_onenand_write_bufferram;
> >  	}
> >  
> >  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> > 
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 10:25:24AM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> On 2017-11-09 11:15, Ladislav Michl wrote:
> > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > Therefore replace open coded timeout waiting for completion in OMAP3
> > functions with API call and merge those two implementations.
> > 
> > Note that currently the is no single DMA user, so this change is basically
> > no-op. Those interested will have to find DMA configuration in the
> > linux-omap.git history.
> 
> fwiw I have two patches for some time to convert the omap2 onenand
> driver to DMAengine:
> https://github.com/omap-audio/linux-audio/commits/peter/linux-next-wip/drivers/mtd/onenand/omap2.c

That is incredible! I was thinking about it as a next step and you already
did all the work.

> I can wait for your series and rebase mine or if you have time can test
> them and see if they can be included in your update series.

I run out of time few days ago already, but this looks so good that it is
worth to delay other work. I'll include it in next version of patch serie.

Also it will allow us to dump 'dma-channel' and use DMA if gpio pin
is configured which was intended logic of original driver. 'dma-channel'
was introduced during mechanical conversion to DT and fortunately it is
not used yet, so we can safely remove it again.

Thanks,
	ladis

> - Péter
> 
> > 
> > Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
> > ---
> >  Changes:
> >  -v3: new patch
> > 
> >  drivers/mtd/onenand/omap2.c | 165 +++-----------------------------------------
> >  1 file changed, 10 insertions(+), 155 deletions(-)
> > 
> > diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
> > index 883993bbe40b..5760e40be008 100644
> > --- a/drivers/mtd/onenand/omap2.c
> > +++ b/drivers/mtd/onenand/omap2.c
> > @@ -289,9 +289,7 @@ static inline int omap2_onenand_bufferram_offset(struct mtd_info *mtd, int area)
> >  	return 0;
> >  }
> >  
> > -#if defined(CONFIG_ARCH_OMAP3) || defined(MULTI_OMAP2)
> > -
> > -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > +static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  					unsigned char *buffer, int offset,
> >  					size_t count)
> >  {
> > @@ -299,10 +297,9 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  	struct onenand_chip *this = mtd->priv;
> >  	dma_addr_t dma_src, dma_dst;
> >  	int bram_offset;
> > -	unsigned long timeout;
> > +	unsigned long t;
> >  	void *buf = (void *)buffer;
> >  	size_t xtra;
> > -	volatile unsigned *done;
> >  
> >  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> >  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -349,15 +346,11 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  	reinit_completion(&c->dma_done);
> >  	omap_start_dma(c->dma_channel);
> >  
> > -	timeout = jiffies + msecs_to_jiffies(20);
> > -	done = &c->dma_done.done;
> > -	while (time_before(jiffies, timeout))
> > -		if (*done)
> > -			break;
> > +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
> >  
> >  	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> >  
> > -	if (!*done) {
> > +	if (!t) {
> >  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
> >  		goto out_copy;
> >  	}
> > @@ -369,7 +362,7 @@ static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> >  	return 0;
> >  }
> >  
> > -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > +static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  					 const unsigned char *buffer,
> >  					 int offset, size_t count)
> >  {
> > @@ -377,9 +370,8 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  	struct onenand_chip *this = mtd->priv;
> >  	dma_addr_t dma_src, dma_dst;
> >  	int bram_offset;
> > -	unsigned long timeout;
> > +	unsigned long t;
> >  	void *buf = (void *)buffer;
> > -	volatile unsigned *done;
> >  
> >  	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> >  	if (bram_offset & 3 || (size_t)buf & 3 || count < 384)
> > @@ -420,15 +412,11 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  	reinit_completion(&c->dma_done);
> >  	omap_start_dma(c->dma_channel);
> >  
> > -	timeout = jiffies + msecs_to_jiffies(20);
> > -	done = &c->dma_done.done;
> > -	while (time_before(jiffies, timeout))
> > -		if (*done)
> > -			break;
> > +	t = wait_for_completion_io_timeout(&c->dma_done, msecs_to_jiffies(20));
> >  
> >  	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> >  
> > -	if (!*done) {
> > +	if (!t) {
> >  		dev_err(&c->pdev->dev, "timeout waiting for DMA\n");
> >  		goto out_copy;
> >  	}
> > @@ -440,134 +428,6 @@ static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> >  	return 0;
> >  }
> >  
> > -#else
> > -
> > -static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > -					unsigned char *buffer, int offset,
> > -					size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > -					 const unsigned char *buffer,
> > -					 int offset, size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -#endif
> > -
> > -#if defined(CONFIG_ARCH_OMAP2) || defined(MULTI_OMAP2)
> > -
> > -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > -					unsigned char *buffer, int offset,
> > -					size_t count)
> > -{
> > -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > -	struct onenand_chip *this = mtd->priv;
> > -	dma_addr_t dma_src, dma_dst;
> > -	int bram_offset;
> > -
> > -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> > -	if (1 || (c->dma_channel < 0) ||
> > -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> > -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> > -		memcpy(buffer, (__force void *)(this->base + bram_offset),
> > -		       count);
> > -		return 0;
> > -	}
> > -
> > -	dma_src = c->phys_base + bram_offset;
> > -	dma_dst = dma_map_single(&c->pdev->dev, buffer, count,
> > -				 DMA_FROM_DEVICE);
> > -	if (dma_mapping_error(&c->pdev->dev, dma_dst)) {
> > -		dev_err(&c->pdev->dev,
> > -			"Couldn't DMA map a %d byte buffer\n",
> > -			count);
> > -		return -1;
> > -	}
> > -
> > -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S32,
> > -				     count / 4, 1, 0, 0, 0);
> > -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				dma_src, 0, 0);
> > -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				 dma_dst, 0, 0);
> > -
> > -	reinit_completion(&c->dma_done);
> > -	omap_start_dma(c->dma_channel);
> > -	wait_for_completion(&c->dma_done);
> > -
> > -	dma_unmap_single(&c->pdev->dev, dma_dst, count, DMA_FROM_DEVICE);
> > -
> > -	return 0;
> > -}
> > -
> > -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > -					 const unsigned char *buffer,
> > -					 int offset, size_t count)
> > -{
> > -	struct omap2_onenand *c = container_of(mtd, struct omap2_onenand, mtd);
> > -	struct onenand_chip *this = mtd->priv;
> > -	dma_addr_t dma_src, dma_dst;
> > -	int bram_offset;
> > -
> > -	bram_offset = omap2_onenand_bufferram_offset(mtd, area) + area + offset;
> > -	/* DMA is not used.  Revisit PM requirements before enabling it. */
> > -	if (1 || (c->dma_channel < 0) ||
> > -	    ((void *) buffer >= (void *) high_memory) || (bram_offset & 3) ||
> > -	    (((unsigned int) buffer) & 3) || (count < 1024) || (count & 3)) {
> > -		memcpy((__force void *)(this->base + bram_offset), buffer,
> > -		       count);
> > -		return 0;
> > -	}
> > -
> > -	dma_src = dma_map_single(&c->pdev->dev, (void *) buffer, count,
> > -				 DMA_TO_DEVICE);
> > -	dma_dst = c->phys_base + bram_offset;
> > -	if (dma_mapping_error(&c->pdev->dev, dma_src)) {
> > -		dev_err(&c->pdev->dev,
> > -			"Couldn't DMA map a %d byte buffer\n",
> > -			count);
> > -		return -1;
> > -	}
> > -
> > -	omap_set_dma_transfer_params(c->dma_channel, OMAP_DMA_DATA_TYPE_S16,
> > -				     count / 2, 1, 0, 0, 0);
> > -	omap_set_dma_src_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				dma_src, 0, 0);
> > -	omap_set_dma_dest_params(c->dma_channel, 0, OMAP_DMA_AMODE_POST_INC,
> > -				 dma_dst, 0, 0);
> > -
> > -	reinit_completion(&c->dma_done);
> > -	omap_start_dma(c->dma_channel);
> > -	wait_for_completion(&c->dma_done);
> > -
> > -	dma_unmap_single(&c->pdev->dev, dma_src, count, DMA_TO_DEVICE);
> > -
> > -	return 0;
> > -}
> > -
> > -#else
> > -
> > -static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
> > -					unsigned char *buffer, int offset,
> > -					size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
> > -					 const unsigned char *buffer,
> > -					 int offset, size_t count)
> > -{
> > -	return -ENOSYS;
> > -}
> > -
> > -#endif
> > -
> >  static struct platform_driver omap2_onenand_driver;
> >  
> >  static void omap2_onenand_shutdown(struct platform_device *pdev)
> > @@ -691,13 +551,8 @@ static int omap2_onenand_probe(struct platform_device *pdev)
> >  	this = &c->onenand;
> >  	if (c->dma_channel >= 0) {
> >  		this->wait = omap2_onenand_wait;
> > -		if (c->flags & ONENAND_IN_OMAP34XX) {
> > -			this->read_bufferram = omap3_onenand_read_bufferram;
> > -			this->write_bufferram = omap3_onenand_write_bufferram;
> > -		} else {
> > -			this->read_bufferram = omap2_onenand_read_bufferram;
> > -			this->write_bufferram = omap2_onenand_write_bufferram;
> > -		}
> > +		this->read_bufferram = omap2_onenand_read_bufferram;
> > +		this->write_bufferram = omap2_onenand_write_bufferram;
> >  	}
> >  
> >  	if ((r = onenand_scan(&c->mtd, 1)) < 0)
> > 
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 10:06]:
> On Fri, Nov 10, 2017 at 10:25:24AM +0200, Peter Ujfalusi wrote:
> > Hi,
> > 
> > On 2017-11-09 11:15, Ladislav Michl wrote:
> > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > functions with API call and merge those two implementations.
> > > 
> > > Note that currently the is no single DMA user, so this change is basically
> > > no-op. Those interested will have to find DMA configuration in the
> > > linux-omap.git history.
> > 
> > fwiw I have two patches for some time to convert the omap2 onenand
> > driver to DMAengine:
> > https://github.com/omap-audio/linux-audio/commits/peter/linux-next-wip/drivers/mtd/onenand/omap2.c
> 
> That is incredible! I was thinking about it as a next step and you already
> did all the work.
> 
> > I can wait for your series and rebase mine or if you have time can test
> > them and see if they can be included in your update series.

Yeah that's great, one step closer to removing the legacy dma support!

> I run out of time few days ago already, but this looks so good that it is
> worth to delay other work. I'll include it in next version of patch serie.
> 
> Also it will allow us to dump 'dma-channel' and use DMA if gpio pin
> is configured which was intended logic of original driver. 'dma-channel'
> was introduced during mechanical conversion to DT and fortunately it is
> not used yet, so we can safely remove it again.

FYI, the gpio pin for onenand should not be in gpio mode. It should
be used as external dma request line to automatically trigger new
transfers like we do for tusb6010 dma. But of course it's possible
that onenand has other issues too preventing the dma usage.

Regards,

Tony

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 10:06]:
> On Fri, Nov 10, 2017 at 10:25:24AM +0200, Peter Ujfalusi wrote:
> > Hi,
> > 
> > On 2017-11-09 11:15, Ladislav Michl wrote:
> > > Since the very first commit (36cd4fb5d277: "[MTD] [OneNAND] Add OMAP2 / OMAP3
> > > OneNAND driver") DMA is disabled for OMAP2. Later fixes thus went only into
> > > OMAP3 specific DMA functions which turned out not to be so OMAP3 specific.
> > > Therefore replace open coded timeout waiting for completion in OMAP3
> > > functions with API call and merge those two implementations.
> > > 
> > > Note that currently the is no single DMA user, so this change is basically
> > > no-op. Those interested will have to find DMA configuration in the
> > > linux-omap.git history.
> > 
> > fwiw I have two patches for some time to convert the omap2 onenand
> > driver to DMAengine:
> > https://github.com/omap-audio/linux-audio/commits/peter/linux-next-wip/drivers/mtd/onenand/omap2.c
> 
> That is incredible! I was thinking about it as a next step and you already
> did all the work.
> 
> > I can wait for your series and rebase mine or if you have time can test
> > them and see if they can be included in your update series.

Yeah that's great, one step closer to removing the legacy dma support!

> I run out of time few days ago already, but this looks so good that it is
> worth to delay other work. I'll include it in next version of patch serie.
> 
> Also it will allow us to dump 'dma-channel' and use DMA if gpio pin
> is configured which was intended logic of original driver. 'dma-channel'
> was introduced during mechanical conversion to DT and fortunately it is
> not used yet, so we can safely remove it again.

FYI, the gpio pin for onenand should not be in gpio mode. It should
be used as external dma request line to automatically trigger new
transfers like we do for tusb6010 dma. But of course it's possible
that onenand has other issues too preventing the dma usage.

Regards,

Tony

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> FYI, the gpio pin for onenand should not be in gpio mode. It should
> be used as external dma request line to automatically trigger new
> transfers like we do for tusb6010 dma. But of course it's possible
> that onenand has other issues too preventing the dma usage.

Hmm, that's probably what comment in omap3-n900.dts is saying:
"sys_ndmareq1 could be used by the driver, not as gpio65 though"
However board-rx51 (is that n900?) is using it as gpio pin.
Also omap2420-n8x0-common.dtsi comment says: "gpio-irq for dma: 26"
and it matches board-n8x0.c platform data configuration.
But I still missing pinmux configuration as we need to add it into
DT as well. I guess this was originally done in bootloader. Any hint
where can I get this info from?

Thanks,
	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> FYI, the gpio pin for onenand should not be in gpio mode. It should
> be used as external dma request line to automatically trigger new
> transfers like we do for tusb6010 dma. But of course it's possible
> that onenand has other issues too preventing the dma usage.

Hmm, that's probably what comment in omap3-n900.dts is saying:
"sys_ndmareq1 could be used by the driver, not as gpio65 though"
However board-rx51 (is that n900?) is using it as gpio pin.
Also omap2420-n8x0-common.dtsi comment says: "gpio-irq for dma: 26"
and it matches board-n8x0.c platform data configuration.
But I still missing pinmux configuration as we need to add it into
DT as well. I guess this was originally done in bootloader. Any hint
where can I get this info from?

Thanks,
	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 18:28]:
> On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > be used as external dma request line to automatically trigger new
> > transfers like we do for tusb6010 dma. But of course it's possible
> > that onenand has other issues too preventing the dma usage.
> 
> Hmm, that's probably what comment in omap3-n900.dts is saying:
> "sys_ndmareq1 could be used by the driver, not as gpio65 though"
> However board-rx51 (is that n900?) is using it as gpio pin.
> Also omap2420-n8x0-common.dtsi comment says: "gpio-irq for dma: 26"
> and it matches board-n8x0.c platform data configuration.
> But I still missing pinmux configuration as we need to add it into
> DT as well. I guess this was originally done in bootloader. Any hint
> where can I get this info from?

Well I have a utility called padconftodts that uses the old kernel
pinmux data :) I'll try to update a bit and push out over next few days.
It can read the /sys/kernel/debug/pinctrl data and convert it to a
dts file with some nice comments.

So I should be able to also dump out the pins for n8x0 and n900.

Regards,

Tony

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 18:28]:
> On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > be used as external dma request line to automatically trigger new
> > transfers like we do for tusb6010 dma. But of course it's possible
> > that onenand has other issues too preventing the dma usage.
> 
> Hmm, that's probably what comment in omap3-n900.dts is saying:
> "sys_ndmareq1 could be used by the driver, not as gpio65 though"
> However board-rx51 (is that n900?) is using it as gpio pin.
> Also omap2420-n8x0-common.dtsi comment says: "gpio-irq for dma: 26"
> and it matches board-n8x0.c platform data configuration.
> But I still missing pinmux configuration as we need to add it into
> DT as well. I guess this was originally done in bootloader. Any hint
> where can I get this info from?

Well I have a utility called padconftodts that uses the old kernel
pinmux data :) I'll try to update a bit and push out over next few days.
It can read the /sys/kernel/debug/pinctrl data and convert it to a
dts file with some nice comments.

So I should be able to also dump out the pins for n8x0 and n900.

Regards,

Tony

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> FYI, the gpio pin for onenand should not be in gpio mode. It should
> be used as external dma request line to automatically trigger new
> transfers like we do for tusb6010 dma. But of course it's possible
> that onenand has other issues too preventing the dma usage.

Now, after reading dma and interrupt related code again, I still do
not see how the driver could be using hardware synchronized transfer.
DMA seems to be used as a memcpy and gpio pin a ready/busy.
Care to elaborate a bit more?

Thank you,
	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> FYI, the gpio pin for onenand should not be in gpio mode. It should
> be used as external dma request line to automatically trigger new
> transfers like we do for tusb6010 dma. But of course it's possible
> that onenand has other issues too preventing the dma usage.

Now, after reading dma and interrupt related code again, I still do
not see how the driver could be using hardware synchronized transfer.
DMA seems to be used as a memcpy and gpio pin a ready/busy.
Care to elaborate a bit more?

Thank you,
	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 21:41]:
> On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > be used as external dma request line to automatically trigger new
> > transfers like we do for tusb6010 dma. But of course it's possible
> > that onenand has other issues too preventing the dma usage.
> 
> Now, after reading dma and interrupt related code again, I still do
> not see how the driver could be using hardware synchronized transfer.
> DMA seems to be used as a memcpy and gpio pin a ready/busy.
> Care to elaborate a bit more?

Well take a look at mux options for the onenand connected pins,
and if there is one that has a mux option for ext_dmareq or similar,
chances are it can be used to retrigger dma transfers.

I could be wrong of course, and it could be it won't even work with
onenand.

Something to look later on for sure if anybody is interested.

Regards,

Tony

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171110 21:41]:
> On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > be used as external dma request line to automatically trigger new
> > transfers like we do for tusb6010 dma. But of course it's possible
> > that onenand has other issues too preventing the dma usage.
> 
> Now, after reading dma and interrupt related code again, I still do
> not see how the driver could be using hardware synchronized transfer.
> DMA seems to be used as a memcpy and gpio pin a ready/busy.
> Care to elaborate a bit more?

Well take a look at mux options for the onenand connected pins,
and if there is one that has a mux option for ext_dmareq or similar,
chances are it can be used to retrigger dma transfers.

I could be wrong of course, and it could be it won't even work with
onenand.

Something to look later on for sure if anybody is interested.

Regards,

Tony

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Tue, Nov 14, 2017 at 01:53:12PM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171110 21:41]:
> > On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > > be used as external dma request line to automatically trigger new
> > > transfers like we do for tusb6010 dma. But of course it's possible
> > > that onenand has other issues too preventing the dma usage.
> > 
> > Now, after reading dma and interrupt related code again, I still do
> > not see how the driver could be using hardware synchronized transfer.
> > DMA seems to be used as a memcpy and gpio pin a ready/busy.
> > Care to elaborate a bit more?
> 
> Well take a look at mux options for the onenand connected pins,
> and if there is one that has a mux option for ext_dmareq or similar,
> chances are it can be used to retrigger dma transfers.
> 
> I could be wrong of course, and it could be it won't even work with
> onenand.

As previously discussed, slave DMA should be triggered by RDY pin
and it has nothing to do with code already in place.

That also means someone should remove misleding comment line from
e2c5eb78a3cc "ARM: dts: Fix wrong GPMC size mappings for omaps" ;-)

I'll do it later in v5 of "ARM: dts: Nokia: Use R/B pin".

> Something to look later on for sure if anybody is interested.

While there, we should also benchmark DMA memcpy as OMAP3 version
was using 384 bytes as limit to trigger DMA while OMAP2 was using
1024. For smaller chunks, memcpy was used. I decided to leave 384
in place, but I do not have OMAP2 hardware to do any verification.

	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Tue, Nov 14, 2017 at 01:53:12PM -0800, Tony Lindgren wrote:
> * Ladislav Michl <ladis@linux-mips.org> [171110 21:41]:
> > On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > > be used as external dma request line to automatically trigger new
> > > transfers like we do for tusb6010 dma. But of course it's possible
> > > that onenand has other issues too preventing the dma usage.
> > 
> > Now, after reading dma and interrupt related code again, I still do
> > not see how the driver could be using hardware synchronized transfer.
> > DMA seems to be used as a memcpy and gpio pin a ready/busy.
> > Care to elaborate a bit more?
> 
> Well take a look at mux options for the onenand connected pins,
> and if there is one that has a mux option for ext_dmareq or similar,
> chances are it can be used to retrigger dma transfers.
> 
> I could be wrong of course, and it could be it won't even work with
> onenand.

As previously discussed, slave DMA should be triggered by RDY pin
and it has nothing to do with code already in place.

That also means someone should remove misleding comment line from
e2c5eb78a3cc "ARM: dts: Fix wrong GPMC size mappings for omaps" ;-)

I'll do it later in v5 of "ARM: dts: Nokia: Use R/B pin".

> Something to look later on for sure if anybody is interested.

While there, we should also benchmark DMA memcpy as OMAP3 version
was using 384 bytes as limit to trigger DMA while OMAP2 was using
1024. For smaller chunks, memcpy was used. I decided to leave 384
in place, but I do not have OMAP2 hardware to do any verification.

	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171114 22:34]:
> On Tue, Nov 14, 2017 at 01:53:12PM -0800, Tony Lindgren wrote:
> > * Ladislav Michl <ladis@linux-mips.org> [171110 21:41]:
> > > On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > > > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > > > be used as external dma request line to automatically trigger new
> > > > transfers like we do for tusb6010 dma. But of course it's possible
> > > > that onenand has other issues too preventing the dma usage.
> > > 
> > > Now, after reading dma and interrupt related code again, I still do
> > > not see how the driver could be using hardware synchronized transfer.
> > > DMA seems to be used as a memcpy and gpio pin a ready/busy.
> > > Care to elaborate a bit more?
> > 
> > Well take a look at mux options for the onenand connected pins,
> > and if there is one that has a mux option for ext_dmareq or similar,
> > chances are it can be used to retrigger dma transfers.
> > 
> > I could be wrong of course, and it could be it won't even work with
> > onenand.
> 
> As previously discussed, slave DMA should be triggered by RDY pin
> and it has nothing to do with code already in place.
> 
> That also means someone should remove misleding comment line from
> e2c5eb78a3cc "ARM: dts: Fix wrong GPMC size mappings for omaps" ;-)
> 
> I'll do it later in v5 of "ARM: dts: Nokia: Use R/B pin".

Well gpio_65 has sys_ndmareq1 mode.. And if it's RDY pin, it to
me sounds like it really could be used for loading more data to
the fifo. But then again, I have not looked at the datasheet so
you probably know better :)

> > Something to look later on for sure if anybody is interested.
> 
> While there, we should also benchmark DMA memcpy as OMAP3 version
> was using 384 bytes as limit to trigger DMA while OMAP2 was using
> 1024. For smaller chunks, memcpy was used. I decided to leave 384
> in place, but I do not have OMAP2 hardware to do any verification.

Yeah testing on n8x0 really should be done to avoid regressions.

Regards,

Tony

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis@linux-mips.org> [171114 22:34]:
> On Tue, Nov 14, 2017 at 01:53:12PM -0800, Tony Lindgren wrote:
> > * Ladislav Michl <ladis@linux-mips.org> [171110 21:41]:
> > > On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote:
> > > > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > > > be used as external dma request line to automatically trigger new
> > > > transfers like we do for tusb6010 dma. But of course it's possible
> > > > that onenand has other issues too preventing the dma usage.
> > > 
> > > Now, after reading dma and interrupt related code again, I still do
> > > not see how the driver could be using hardware synchronized transfer.
> > > DMA seems to be used as a memcpy and gpio pin a ready/busy.
> > > Care to elaborate a bit more?
> > 
> > Well take a look at mux options for the onenand connected pins,
> > and if there is one that has a mux option for ext_dmareq or similar,
> > chances are it can be used to retrigger dma transfers.
> > 
> > I could be wrong of course, and it could be it won't even work with
> > onenand.
> 
> As previously discussed, slave DMA should be triggered by RDY pin
> and it has nothing to do with code already in place.
> 
> That also means someone should remove misleding comment line from
> e2c5eb78a3cc "ARM: dts: Fix wrong GPMC size mappings for omaps" ;-)
> 
> I'll do it later in v5 of "ARM: dts: Nokia: Use R/B pin".

Well gpio_65 has sys_ndmareq1 mode.. And if it's RDY pin, it to
me sounds like it really could be used for loading more data to
the fifo. But then again, I have not looked at the datasheet so
you probably know better :)

> > Something to look later on for sure if anybody is interested.
> 
> While there, we should also benchmark DMA memcpy as OMAP3 version
> was using 384 bytes as limit to trigger DMA while OMAP2 was using
> 1024. For smaller chunks, memcpy was used. I decided to leave 384
> in place, but I do not have OMAP2 hardware to do any verification.

Yeah testing on n8x0 really should be done to avoid regressions.

Regards,

Tony

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]

On 2017-11-10 17:24, Tony Lindgren wrote:
>> I run out of time few days ago already, but this looks so good that it is
>> worth to delay other work. I'll include it in next version of patch serie.
>>
>> Also it will allow us to dump 'dma-channel' and use DMA if gpio pin
>> is configured which was intended logic of original driver. 'dma-channel'
>> was introduced during mechanical conversion to DT and fortunately it is
>> not used yet, so we can safely remove it again.
> 
> FYI, the gpio pin for onenand should not be in gpio mode. It should
> be used as external dma request line to automatically trigger new
> transfers like we do for tusb6010 dma. But of course it's possible
> that onenand has other issues too preventing the dma usage.

My conversion to DMAengine is drop in replacement of the existing
implementation: memcpy w/o hardware synchronization event.

But I think it should be possible to use HW sync (slave DMA) with the
src/dst_port_window in a similar way we do with the tusb6010.

But that can be done in a followup series, but what to do in case of old
DT where the dmas/dma-names properties are no there?

Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.

Having said that, there might have been a reason why the original
implementation was not using DMA request to trigger the memcpy... The
legacy omap-dma API would have allowed that as you kind of open code
things with much flexibility.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]

On 2017-11-10 17:24, Tony Lindgren wrote:
>> I run out of time few days ago already, but this looks so good that it is
>> worth to delay other work. I'll include it in next version of patch serie.
>>
>> Also it will allow us to dump 'dma-channel' and use DMA if gpio pin
>> is configured which was intended logic of original driver. 'dma-channel'
>> was introduced during mechanical conversion to DT and fortunately it is
>> not used yet, so we can safely remove it again.
> 
> FYI, the gpio pin for onenand should not be in gpio mode. It should
> be used as external dma request line to automatically trigger new
> transfers like we do for tusb6010 dma. But of course it's possible
> that onenand has other issues too preventing the dma usage.

My conversion to DMAengine is drop in replacement of the existing
implementation: memcpy w/o hardware synchronization event.

But I think it should be possible to use HW sync (slave DMA) with the
src/dst_port_window in a similar way we do with the tusb6010.

But that can be done in a followup series, but what to do in case of old
DT where the dmas/dma-names properties are no there?

Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.

Having said that, there might have been a reason why the original
implementation was not using DMA request to trigger the memcpy... The
legacy omap-dma API would have allowed that as you kind of open code
things with much flexibility.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
> 
> On 2017-11-10 17:24, Tony Lindgren wrote:
> > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > be used as external dma request line to automatically trigger new
> > transfers like we do for tusb6010 dma. But of course it's possible
> > that onenand has other issues too preventing the dma usage.
> 
> My conversion to DMAengine is drop in replacement of the existing
> implementation: memcpy w/o hardware synchronization event.
> 
> But I think it should be possible to use HW sync (slave DMA) with the
> src/dst_port_window in a similar way we do with the tusb6010.

How do you want to synchronize it from OneNAND side?

> But that can be done in a followup series, but what to do in case of old
> DT where the dmas/dma-names properties are no there?

These will not work anyway as they do not have compatible property.
Also note, that DMA is currently not used, yet nobody complained.

> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
> 
> Having said that, there might have been a reason why the original
> implementation was not using DMA request to trigger the memcpy... The
> legacy omap-dma API would have allowed that as you kind of open code
> things with much flexibility.

That's mainly problem of OneNAND driver itself, not oma-dma. But do we
really want to invest more time to this obsolete technology?

Of course, I would love to see my 10+ years old boards running faster,
but it seems unrealistic to me to get enough manpower to finish this task.

	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
> 
> On 2017-11-10 17:24, Tony Lindgren wrote:
> > FYI, the gpio pin for onenand should not be in gpio mode. It should
> > be used as external dma request line to automatically trigger new
> > transfers like we do for tusb6010 dma. But of course it's possible
> > that onenand has other issues too preventing the dma usage.
> 
> My conversion to DMAengine is drop in replacement of the existing
> implementation: memcpy w/o hardware synchronization event.
> 
> But I think it should be possible to use HW sync (slave DMA) with the
> src/dst_port_window in a similar way we do with the tusb6010.

How do you want to synchronize it from OneNAND side?

> But that can be done in a followup series, but what to do in case of old
> DT where the dmas/dma-names properties are no there?

These will not work anyway as they do not have compatible property.
Also note, that DMA is currently not used, yet nobody complained.

> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
> 
> Having said that, there might have been a reason why the original
> implementation was not using DMA request to trigger the memcpy... The
> legacy omap-dma API would have allowed that as you kind of open code
> things with much flexibility.

That's mainly problem of OneNAND driver itself, not oma-dma. But do we
really want to invest more time to this obsolete technology?

Of course, I would love to see my 10+ years old boards running faster,
but it seems unrealistic to me to get enough manpower to finish this task.

	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]

On 2017-11-13 14:15, Ladislav Michl wrote:
> On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
>>
>> On 2017-11-10 17:24, Tony Lindgren wrote:
>>> FYI, the gpio pin for onenand should not be in gpio mode. It should
>>> be used as external dma request line to automatically trigger new
>>> transfers like we do for tusb6010 dma. But of course it's possible
>>> that onenand has other issues too preventing the dma usage.
>>
>> My conversion to DMAengine is drop in replacement of the existing
>> implementation: memcpy w/o hardware synchronization event.
>>
>> But I think it should be possible to use HW sync (slave DMA) with the
>> src/dst_port_window in a similar way we do with the tusb6010.
> 
> How do you want to synchronize it from OneNAND side?

_if_ the pin used as GPIO interrupt has ext DMA request mode then we can
switch it, in the DT bindings we give the extDMA request as sync event
and convert the driver: remove GPIO irq handling and have slave DMA
setup with port_window to do kind of memcpy with HW synchronization.

It might be possible... It was possible with tusb6010, but that one was
already using hw sync with the legacy omap-dma API.

>> But that can be done in a followup series, but what to do in case of old
>> DT where the dmas/dma-names properties are no there?
> 
> These will not work anyway as they do not have compatible property.
> Also note, that DMA is currently not used, yet nobody complained.

;)

>> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
>>
>> Having said that, there might have been a reason why the original
>> implementation was not using DMA request to trigger the memcpy... The
>> legacy omap-dma API would have allowed that as you kind of open code
>> things with much flexibility.
> 
> That's mainly problem of OneNAND driver itself, not oma-dma. But do we
> really want to invest more time to this obsolete technology?
> 
> Of course, I would love to see my 10+ years old boards running faster,
> but it seems unrealistic to me to get enough manpower to finish this task.

Valid point. I would - for now - only do the DMAengine memcpy conversion
with the GPIO irq and investigate the slave DMA support after that.

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

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Peter Ujfalusi]

On 2017-11-13 14:15, Ladislav Michl wrote:
> On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
>>
>> On 2017-11-10 17:24, Tony Lindgren wrote:
>>> FYI, the gpio pin for onenand should not be in gpio mode. It should
>>> be used as external dma request line to automatically trigger new
>>> transfers like we do for tusb6010 dma. But of course it's possible
>>> that onenand has other issues too preventing the dma usage.
>>
>> My conversion to DMAengine is drop in replacement of the existing
>> implementation: memcpy w/o hardware synchronization event.
>>
>> But I think it should be possible to use HW sync (slave DMA) with the
>> src/dst_port_window in a similar way we do with the tusb6010.
> 
> How do you want to synchronize it from OneNAND side?

_if_ the pin used as GPIO interrupt has ext DMA request mode then we can
switch it, in the DT bindings we give the extDMA request as sync event
and convert the driver: remove GPIO irq handling and have slave DMA
setup with port_window to do kind of memcpy with HW synchronization.

It might be possible... It was possible with tusb6010, but that one was
already using hw sync with the legacy omap-dma API.

>> But that can be done in a followup series, but what to do in case of old
>> DT where the dmas/dma-names properties are no there?
> 
> These will not work anyway as they do not have compatible property.
> Also note, that DMA is currently not used, yet nobody complained.

;)

>> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
>>
>> Having said that, there might have been a reason why the original
>> implementation was not using DMA request to trigger the memcpy... The
>> legacy omap-dma API would have allowed that as you kind of open code
>> things with much flexibility.
> 
> That's mainly problem of OneNAND driver itself, not oma-dma. But do we
> really want to invest more time to this obsolete technology?
> 
> Of course, I would love to see my 10+ years old boards running faster,
> but it seems unrealistic to me to get enough manpower to finish this task.

Valid point. I would - for now - only do the DMAengine memcpy conversion
with the GPIO irq and investigate the slave DMA support after that.

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

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [171113 14:37]:
> On 2017-11-13 14:15, Ladislav Michl wrote:
> > Of course, I would love to see my 10+ years old boards running faster,
> > but it seems unrealistic to me to get enough manpower to finish this task.
> 
> Valid point. I would - for now - only do the DMAengine memcpy conversion
> with the GPIO irq and investigate the slave DMA support after that.

Yeah the use of the dmareq line is up to somebody who needs it naturally,
just something we've ben speculating for a while :)

Regards,

Tony

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [171113 14:37]:
> On 2017-11-13 14:15, Ladislav Michl wrote:
> > Of course, I would love to see my 10+ years old boards running faster,
> > but it seems unrealistic to me to get enough manpower to finish this task.
> 
> Valid point. I would - for now - only do the DMAengine memcpy conversion
> with the GPIO irq and investigate the slave DMA support after that.

Yeah the use of the dmareq line is up to somebody who needs it naturally,
just something we've ben speculating for a while :)

Regards,

Tony

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Mon, Nov 13, 2017 at 04:36:41PM +0200, Peter Ujfalusi wrote:
> 
> 
> On 2017-11-13 14:15, Ladislav Michl wrote:
> > On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
> >>
> >> On 2017-11-10 17:24, Tony Lindgren wrote:
> >>> FYI, the gpio pin for onenand should not be in gpio mode. It should
> >>> be used as external dma request line to automatically trigger new
> >>> transfers like we do for tusb6010 dma. But of course it's possible
> >>> that onenand has other issues too preventing the dma usage.
> >>
> >> My conversion to DMAengine is drop in replacement of the existing
> >> implementation: memcpy w/o hardware synchronization event.
> >>
> >> But I think it should be possible to use HW sync (slave DMA) with the
> >> src/dst_port_window in a similar way we do with the tusb6010.
> > 
> > How do you want to synchronize it from OneNAND side?
> 
> _if_ the pin used as GPIO interrupt has ext DMA request mode then we can
> switch it, in the DT bindings we give the extDMA request as sync event
> and convert the driver: remove GPIO irq handling and have slave DMA
> setup with port_window to do kind of memcpy with HW synchronization.

Well, the pin used as GPIO interrupt has this purpose, according to specs:
"The OneNAND INT pin is an output pin function used to notify the Host when
a command has been completed. This provides a hardware method of signaling
the completion of a program, erase, or load operation".

See for example section 3.9 (and later) of specs:
https://www.abcelectronique.com/composants/telechargement_datasheet.php?id=1089396&part-number=KFH2G16Q2A-DEBx

> It might be possible... It was possible with tusb6010, but that one was
> already using hw sync with the legacy omap-dma API.

Based on above, it seems there's long and hard way :)

> >> But that can be done in a followup series, but what to do in case of old
> >> DT where the dmas/dma-names properties are no there?
> > 
> > These will not work anyway as they do not have compatible property.
> > Also note, that DMA is currently not used, yet nobody complained.
> 
> ;)
> 
> >> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
> >>
> >> Having said that, there might have been a reason why the original
> >> implementation was not using DMA request to trigger the memcpy... The
> >> legacy omap-dma API would have allowed that as you kind of open code
> >> things with much flexibility.
> > 
> > That's mainly problem of OneNAND driver itself, not oma-dma. But do we
> > really want to invest more time to this obsolete technology?
> > 
> > Of course, I would love to see my 10+ years old boards running faster,
> > but it seems unrealistic to me to get enough manpower to finish this task.
> 
> Valid point. I would - for now - only do the DMAengine memcpy conversion
> with the GPIO irq and investigate the slave DMA support after that.

Here it would be nice to have the same documentation Nokia had at the time
writing support for n8x0 as they clearly used few undocumented features.
Please see section 3.9.5 of above mentioned specs. Seems DMA slave should
be triggered by RDY not INT pin.

Best regards,
	ladis

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Mon, Nov 13, 2017 at 04:36:41PM +0200, Peter Ujfalusi wrote:
> 
> 
> On 2017-11-13 14:15, Ladislav Michl wrote:
> > On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
> >>
> >> On 2017-11-10 17:24, Tony Lindgren wrote:
> >>> FYI, the gpio pin for onenand should not be in gpio mode. It should
> >>> be used as external dma request line to automatically trigger new
> >>> transfers like we do for tusb6010 dma. But of course it's possible
> >>> that onenand has other issues too preventing the dma usage.
> >>
> >> My conversion to DMAengine is drop in replacement of the existing
> >> implementation: memcpy w/o hardware synchronization event.
> >>
> >> But I think it should be possible to use HW sync (slave DMA) with the
> >> src/dst_port_window in a similar way we do with the tusb6010.
> > 
> > How do you want to synchronize it from OneNAND side?
> 
> _if_ the pin used as GPIO interrupt has ext DMA request mode then we can
> switch it, in the DT bindings we give the extDMA request as sync event
> and convert the driver: remove GPIO irq handling and have slave DMA
> setup with port_window to do kind of memcpy with HW synchronization.

Well, the pin used as GPIO interrupt has this purpose, according to specs:
"The OneNAND INT pin is an output pin function used to notify the Host when
a command has been completed. This provides a hardware method of signaling
the completion of a program, erase, or load operation".

See for example section 3.9 (and later) of specs:
https://www.abcelectronique.com/composants/telechargement_datasheet.php?id=1089396&part-number=KFH2G16Q2A-DEBx

> It might be possible... It was possible with tusb6010, but that one was
> already using hw sync with the legacy omap-dma API.

Based on above, it seems there's long and hard way :)

> >> But that can be done in a followup series, but what to do in case of old
> >> DT where the dmas/dma-names properties are no there?
> > 
> > These will not work anyway as they do not have compatible property.
> > Also note, that DMA is currently not used, yet nobody complained.
> 
> ;)
> 
> >> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
> >>
> >> Having said that, there might have been a reason why the original
> >> implementation was not using DMA request to trigger the memcpy... The
> >> legacy omap-dma API would have allowed that as you kind of open code
> >> things with much flexibility.
> > 
> > That's mainly problem of OneNAND driver itself, not oma-dma. But do we
> > really want to invest more time to this obsolete technology?
> > 
> > Of course, I would love to see my 10+ years old boards running faster,
> > but it seems unrealistic to me to get enough manpower to finish this task.
> 
> Valid point. I would - for now - only do the DMAengine memcpy conversion
> with the GPIO irq and investigate the slave DMA support after that.

Here it would be nice to have the same documentation Nokia had at the time
writing support for n8x0 as they clearly used few undocumented features.
Please see section 3.9.5 of above mentioned specs. Seems DMA slave should
be triggered by RDY not INT pin.

Best regards,
	ladis

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Roger Quadros]

On 13/11/17 17:27, Ladislav Michl wrote:
> On Mon, Nov 13, 2017 at 04:36:41PM +0200, Peter Ujfalusi wrote:
>>
>>
>> On 2017-11-13 14:15, Ladislav Michl wrote:
>>> On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
>>>>
>>>> On 2017-11-10 17:24, Tony Lindgren wrote:
>>>>> FYI, the gpio pin for onenand should not be in gpio mode. It should
>>>>> be used as external dma request line to automatically trigger new
>>>>> transfers like we do for tusb6010 dma. But of course it's possible
>>>>> that onenand has other issues too preventing the dma usage.
>>>>
>>>> My conversion to DMAengine is drop in replacement of the existing
>>>> implementation: memcpy w/o hardware synchronization event.
>>>>
>>>> But I think it should be possible to use HW sync (slave DMA) with the
>>>> src/dst_port_window in a similar way we do with the tusb6010.
>>>
>>> How do you want to synchronize it from OneNAND side?
>>
>> _if_ the pin used as GPIO interrupt has ext DMA request mode then we can
>> switch it, in the DT bindings we give the extDMA request as sync event
>> and convert the driver: remove GPIO irq handling and have slave DMA
>> setup with port_window to do kind of memcpy with HW synchronization.
> 
> Well, the pin used as GPIO interrupt has this purpose, according to specs:
> "The OneNAND INT pin is an output pin function used to notify the Host when
> a command has been completed. This provides a hardware method of signaling
> the completion of a program, erase, or load operation".
> 
> See for example section 3.9 (and later) of specs:
> https://www.abcelectronique.com/composants/telechargement_datasheet.php?id=1089396&part-number=KFH2G16Q2A-DEBx

Also see section 7.1 Methods of Determining Interrupt Status.

Based on that INT pin is analogous to NAND Read/Busy pin and has nothing to do
with DMA.

> 
>> It might be possible... It was possible with tusb6010, but that one was
>> already using hw sync with the legacy omap-dma API.
> 
> Based on above, it seems there's long and hard way :)
> 
>>>> But that can be done in a followup series, but what to do in case of old
>>>> DT where the dmas/dma-names properties are no there?
>>>
>>> These will not work anyway as they do not have compatible property.
>>> Also note, that DMA is currently not used, yet nobody complained.
>>
>> ;)
>>
>>>> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
>>>>
>>>> Having said that, there might have been a reason why the original
>>>> implementation was not using DMA request to trigger the memcpy... The
>>>> legacy omap-dma API would have allowed that as you kind of open code
>>>> things with much flexibility.
>>>
>>> That's mainly problem of OneNAND driver itself, not oma-dma. But do we
>>> really want to invest more time to this obsolete technology?
>>>
>>> Of course, I would love to see my 10+ years old boards running faster,
>>> but it seems unrealistic to me to get enough manpower to finish this task.
>>
>> Valid point. I would - for now - only do the DMAengine memcpy conversion
>> with the GPIO irq and investigate the slave DMA support after that.
> 
> Here it would be nice to have the same documentation Nokia had at the time
> writing support for n8x0 as they clearly used few undocumented features.
> Please see section 3.9.5 of above mentioned specs. Seems DMA slave should
> be triggered by RDY not INT pin.

Correct. For RDY pin usage See 3.7.3 Handshaking Operation

"The handshaking feature allows the host system to simply monitor the RDY signal from the device to determine
when the initial word of burst data is ready to be read."

> 
> Best regards,
> 	ladis
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Roger Quadros]

On 13/11/17 17:27, Ladislav Michl wrote:
> On Mon, Nov 13, 2017 at 04:36:41PM +0200, Peter Ujfalusi wrote:
>>
>>
>> On 2017-11-13 14:15, Ladislav Michl wrote:
>>> On Mon, Nov 13, 2017 at 10:22:12AM +0200, Peter Ujfalusi wrote:
>>>>
>>>> On 2017-11-10 17:24, Tony Lindgren wrote:
>>>>> FYI, the gpio pin for onenand should not be in gpio mode. It should
>>>>> be used as external dma request line to automatically trigger new
>>>>> transfers like we do for tusb6010 dma. But of course it's possible
>>>>> that onenand has other issues too preventing the dma usage.
>>>>
>>>> My conversion to DMAengine is drop in replacement of the existing
>>>> implementation: memcpy w/o hardware synchronization event.
>>>>
>>>> But I think it should be possible to use HW sync (slave DMA) with the
>>>> src/dst_port_window in a similar way we do with the tusb6010.
>>>
>>> How do you want to synchronize it from OneNAND side?
>>
>> _if_ the pin used as GPIO interrupt has ext DMA request mode then we can
>> switch it, in the DT bindings we give the extDMA request as sync event
>> and convert the driver: remove GPIO irq handling and have slave DMA
>> setup with port_window to do kind of memcpy with HW synchronization.
> 
> Well, the pin used as GPIO interrupt has this purpose, according to specs:
> "The OneNAND INT pin is an output pin function used to notify the Host when
> a command has been completed. This provides a hardware method of signaling
> the completion of a program, erase, or load operation".
> 
> See for example section 3.9 (and later) of specs:
> https://www.abcelectronique.com/composants/telechargement_datasheet.php?id=1089396&part-number=KFH2G16Q2A-DEBx

Also see section 7.1 Methods of Determining Interrupt Status.

Based on that INT pin is analogous to NAND Read/Busy pin and has nothing to do
with DMA.

> 
>> It might be possible... It was possible with tusb6010, but that one was
>> already using hw sync with the legacy omap-dma API.
> 
> Based on above, it seems there's long and hard way :)
> 
>>>> But that can be done in a followup series, but what to do in case of old
>>>> DT where the dmas/dma-names properties are no there?
>>>
>>> These will not work anyway as they do not have compatible property.
>>> Also note, that DMA is currently not used, yet nobody complained.
>>
>> ;)
>>
>>>> Hmm, extending the dma_slave_map in mach-omap1/2/dma.c might work just fine.
>>>>
>>>> Having said that, there might have been a reason why the original
>>>> implementation was not using DMA request to trigger the memcpy... The
>>>> legacy omap-dma API would have allowed that as you kind of open code
>>>> things with much flexibility.
>>>
>>> That's mainly problem of OneNAND driver itself, not oma-dma. But do we
>>> really want to invest more time to this obsolete technology?
>>>
>>> Of course, I would love to see my 10+ years old boards running faster,
>>> but it seems unrealistic to me to get enough manpower to finish this task.
>>
>> Valid point. I would - for now - only do the DMAengine memcpy conversion
>> with the GPIO irq and investigate the slave DMA support after that.
> 
> Here it would be nice to have the same documentation Nokia had at the time
> writing support for n8x0 as they clearly used few undocumented features.
> Please see section 3.9.5 of above mentioned specs. Seems DMA slave should
> be triggered by RDY not INT pin.

Correct. For RDY pin usage See 3.7.3 Handshaking Operation

"The handshaking feature allows the host system to simply monitor the RDY signal from the device to determine
when the initial word of burst data is ready to be read."

> 
> Best regards,
> 	ladis
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Tue, Nov 14, 2017 at 05:05:20PM +0200, Roger Quadros wrote:
> On 13/11/17 17:27, Ladislav Michl wrote:
> > Here it would be nice to have the same documentation Nokia had at the time
> > writing support for n8x0 as they clearly used few undocumented features.
> > Please see section 3.9.5 of above mentioned specs. Seems DMA slave should
> > be triggered by RDY not INT pin.
> 
> Correct. For RDY pin usage See 3.7.3 Handshaking Operation
> 
> "The handshaking feature allows the host system to simply monitor the RDY signal from the device to determine
> when the initial word of burst data is ready to be read."

To collect more documentation from Samsung, this appnote is also relevant:
http://trendol.free.fr/SMDK6410/842440S3C6410_ApplicationNotes_rev10.pdf
Section 7. OneNand, especially 7.5.1.3-6.

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

Re: [PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Ladislav Michl]

On Tue, Nov 14, 2017 at 05:05:20PM +0200, Roger Quadros wrote:
> On 13/11/17 17:27, Ladislav Michl wrote:
> > Here it would be nice to have the same documentation Nokia had at the time
> > writing support for n8x0 as they clearly used few undocumented features.
> > Please see section 3.9.5 of above mentioned specs. Seems DMA slave should
> > be triggered by RDY not INT pin.
> 
> Correct. For RDY pin usage See 3.7.3 Handshaking Operation
> 
> "The handshaking feature allows the host system to simply monitor the RDY signal from the device to determine
> when the initial word of burst data is ready to be read."

To collect more documentation from Samsung, this appnote is also relevant:
http://trendol.free.fr/SMDK6410/842440S3C6410_ApplicationNotes_rev10.pdf
Section 7. OneNand, especially 7.5.1.3-6.

[PATCH v3 6/7] mtd: onenand: omap2: Do not make delay for GPIO OMAP3 specific

[Ladislav Michl]

Second commit in driver history (782b7a367d81: "[MTD] [OneNAND] OMAP3:
add delay for GPIO") added quirk for waiting until GPIO line settle.
As DMA was disabled for OMAP2 boards, chances are this problem was
not OMAP3 specific and as it is just one register read, previous
test for SoC type is approximately as expensive as read itself.
Make delay unconditional, which allows removing SoC specific code
alltogether.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v3: new patch

 drivers/mtd/onenand/omap2.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 5760e40be008..13da0b8c418b 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -58,7 +58,6 @@ struct omap2_onenand {
 	int dma_channel;
 	int freq;
 	int (*setup)(void __iomem *base, int *freq_ptr);
-	u8 flags;
 };
 
 static void omap2_onenand_dma_cb(int lch, u16 ch_status, void *data)
@@ -151,9 +150,8 @@ static int omap2_onenand_wait(struct mtd_info *mtd, int state)
 		if (!(syscfg & ONENAND_SYS_CFG1_IOBE)) {
 			syscfg |= ONENAND_SYS_CFG1_IOBE;
 			write_reg(c, syscfg, ONENAND_REG_SYS_CFG1);
-			if (c->flags & ONENAND_IN_OMAP34XX)
-				/* Add a delay to let GPIO settle */
-				syscfg = read_reg(c, ONENAND_REG_SYS_CFG1);
+			/* Add a delay to let GPIO settle */
+			syscfg = read_reg(c, ONENAND_REG_SYS_CFG1);
 		}
 
 		reinit_completion(&c->irq_done);
@@ -461,7 +459,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 
 	init_completion(&c->irq_done);
 	init_completion(&c->dma_done);
-	c->flags = pdata->flags;
 	c->gpmc_cs = pdata->cs;
 	c->gpio_irq = pdata->gpio_irq;
 	c->dma_channel = pdata->dma_channel;
-- 
2.11.0


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

[PATCH v3 6/7] mtd: onenand: omap2: Do not make delay for GPIO OMAP3 specific

[Ladislav Michl]

Second commit in driver history (782b7a367d81: "[MTD] [OneNAND] OMAP3:
add delay for GPIO") added quirk for waiting until GPIO line settle.
As DMA was disabled for OMAP2 boards, chances are this problem was
not OMAP3 specific and as it is just one register read, previous
test for SoC type is approximately as expensive as read itself.
Make delay unconditional, which allows removing SoC specific code
alltogether.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v3: new patch

 drivers/mtd/onenand/omap2.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 5760e40be008..13da0b8c418b 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -58,7 +58,6 @@ struct omap2_onenand {
 	int dma_channel;
 	int freq;
 	int (*setup)(void __iomem *base, int *freq_ptr);
-	u8 flags;
 };
 
 static void omap2_onenand_dma_cb(int lch, u16 ch_status, void *data)
@@ -151,9 +150,8 @@ static int omap2_onenand_wait(struct mtd_info *mtd, int state)
 		if (!(syscfg & ONENAND_SYS_CFG1_IOBE)) {
 			syscfg |= ONENAND_SYS_CFG1_IOBE;
 			write_reg(c, syscfg, ONENAND_REG_SYS_CFG1);
-			if (c->flags & ONENAND_IN_OMAP34XX)
-				/* Add a delay to let GPIO settle */
-				syscfg = read_reg(c, ONENAND_REG_SYS_CFG1);
+			/* Add a delay to let GPIO settle */
+			syscfg = read_reg(c, ONENAND_REG_SYS_CFG1);
 		}
 
 		reinit_completion(&c->irq_done);
@@ -461,7 +459,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 
 	init_completion(&c->irq_done);
 	init_completion(&c->dma_done);
-	c->flags = pdata->flags;
 	c->gpmc_cs = pdata->cs;
 	c->gpio_irq = pdata->gpio_irq;
 	c->dma_channel = pdata->dma_channel;
-- 
2.11.0

[PATCH v3 7/7] mtd: onenand: omap2: Configure driver from DT

[Ladislav Michl]

Move away from platform data configuration and use pure DT approach.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: move cleanups into separate patches
      simplify dma setup
      fix checkpatch error
      print info about otimized timings in sync mode only
 -v3: remove 'ti,omap3-onenand' compatible as it is not needed anymore

 drivers/mtd/onenand/omap2.c | 304 ++++++++++++++++++++++++++------------------
 1 file changed, 180 insertions(+), 124 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 13da0b8c418b..4a3fee84a5ac 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -28,16 +28,17 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/onenand.h>
 #include <linux/mtd/partitions.h>
+#include <linux/of_device.h>
+#include <linux/omap-gpmc.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/slab.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 #include <asm/mach/flash.h>
-#include <linux/platform_data/mtd-onenand-omap2.h>
 
 #include <linux/omap-dma.h>
 
@@ -49,15 +50,12 @@ struct omap2_onenand {
 	struct platform_device *pdev;
 	int gpmc_cs;
 	unsigned long phys_base;
-	unsigned int mem_size;
-	int gpio_irq;
+	struct gpio_desc *gpiod;
 	struct mtd_info mtd;
 	struct onenand_chip onenand;
 	struct completion irq_done;
 	struct completion dma_done;
 	int dma_channel;
-	int freq;
-	int (*setup)(void __iomem *base, int *freq_ptr);
 };
 
 static void omap2_onenand_dma_cb(int lch, u16 ch_status, void *data)
@@ -87,6 +85,65 @@ static inline void write_reg(struct omap2_onenand *c, unsigned short value,
 	writew(value, c->onenand.base + reg);
 }
 
+static int omap2_onenand_set_cfg(struct omap2_onenand *c,
+				 bool sr, bool sw,
+				 int latency, int burst_len)
+{
+	unsigned short reg = ONENAND_SYS_CFG1_RDY | ONENAND_SYS_CFG1_INT;
+
+	reg |= latency << ONENAND_SYS_CFG1_BRL_SHIFT;
+
+	switch (burst_len) {
+	case 0:		/* continuous */
+		break;
+	case 4:
+		reg |= ONENAND_SYS_CFG1_BL_4;
+		break;
+	case 8:
+		reg |= ONENAND_SYS_CFG1_BL_8;
+		break;
+	case 16:
+		reg |= ONENAND_SYS_CFG1_BL_16;
+		break;
+	case 32:
+		reg |= ONENAND_SYS_CFG1_BL_32;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (latency > 5)
+		reg |= ONENAND_SYS_CFG1_HF;
+	if (latency > 7)
+		reg |= ONENAND_SYS_CFG1_VHF;
+	if (sr)
+		reg |= ONENAND_SYS_CFG1_SYNC_READ;
+	if (sw)
+		reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
+
+	write_reg(c, reg, ONENAND_REG_SYS_CFG1);
+
+	return 0;
+}
+
+static int omap2_onenand_get_freq(int ver)
+{
+	switch ((ver >> 4) & 0xf) {
+	case 0:
+		return 40;
+	case 1:
+		return 54;
+	case 2:
+		return 66;
+	case 3:
+		return 83;
+	case 4:
+		return 104;
+	}
+
+	return -EINVAL;
+}
+
 static void wait_err(char *msg, int state, unsigned int ctrl, unsigned int intr)
 {
 	printk(KERN_ERR "onenand_wait: %s! state %d ctrl 0x%04x intr 0x%04x\n",
@@ -155,17 +212,13 @@ static int omap2_onenand_wait(struct mtd_info *mtd, int state)
 		}
 
 		reinit_completion(&c->irq_done);
-		if (c->gpio_irq) {
-			result = gpio_get_value(c->gpio_irq);
-			if (result == -1) {
-				ctrl = read_reg(c, ONENAND_REG_CTRL_STATUS);
-				intr = read_reg(c, ONENAND_REG_INTERRUPT);
-				wait_err("gpio error", state, ctrl, intr);
-				return -EIO;
-			}
-		} else
-			result = 0;
-		if (result == 0) {
+		result = c->gpiod ? gpiod_get_value(c->gpiod) : 0;
+		if (result < 0) {
+			ctrl = read_reg(c, ONENAND_REG_CTRL_STATUS);
+			intr = read_reg(c, ONENAND_REG_INTERRUPT);
+			wait_err("gpio error", state, ctrl, intr);
+			return result;
+		} else if (result == 0) {
 			int retry_cnt = 0;
 retry:
 			result = wait_for_completion_timeout(&c->irq_done,
@@ -426,8 +479,6 @@ static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	return 0;
 }
 
-static struct platform_driver omap2_onenand_driver;
-
 static void omap2_onenand_shutdown(struct platform_device *pdev)
 {
 	struct omap2_onenand *c = dev_get_drvdata(&pdev->dev);
@@ -441,120 +492,136 @@ static void omap2_onenand_shutdown(struct platform_device *pdev)
 
 static int omap2_onenand_probe(struct platform_device *pdev)
 {
-	struct omap_onenand_platform_data *pdata;
-	struct omap2_onenand *c;
-	struct onenand_chip *this;
-	int r;
+	u32 val;
+	int freq, latency, r;
+	unsigned int mem_size;
 	struct resource *res;
+	struct omap2_onenand *c;
+	struct gpmc_onenand_info info;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
 
-	pdata = dev_get_platdata(&pdev->dev);
-	if (pdata == NULL) {
-		dev_err(&pdev->dev, "platform data missing\n");
-		return -ENODEV;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "error getting memory resource\n");
+		return -EINVAL;
+	}
+
+	r = of_property_read_u32(np, "reg", &val);
+	if (r) {
+		dev_err(dev, "reg not found in DT\n");
+		return r;
 	}
 
-	c = kzalloc(sizeof(struct omap2_onenand), GFP_KERNEL);
+	c = devm_kzalloc(dev, sizeof(struct omap2_onenand), GFP_KERNEL);
 	if (!c)
 		return -ENOMEM;
 
 	init_completion(&c->irq_done);
 	init_completion(&c->dma_done);
-	c->gpmc_cs = pdata->cs;
-	c->gpio_irq = pdata->gpio_irq;
-	c->dma_channel = pdata->dma_channel;
-	if (c->dma_channel < 0) {
-		/* if -1, don't use DMA */
-		c->gpio_irq = 0;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL) {
-		r = -EINVAL;
-		dev_err(&pdev->dev, "error getting memory resource\n");
-		goto err_kfree;
-	}
-
+	c->gpmc_cs = val;
+	c->dma_channel = -1;
 	c->phys_base = res->start;
-	c->mem_size = resource_size(res);
-
-	if (request_mem_region(c->phys_base, c->mem_size,
-			       pdev->dev.driver->name) == NULL) {
-		dev_err(&pdev->dev, "Cannot reserve memory region at 0x%08lx, size: 0x%x\n",
-						c->phys_base, c->mem_size);
-		r = -EBUSY;
-		goto err_kfree;
-	}
-	c->onenand.base = ioremap(c->phys_base, c->mem_size);
-	if (c->onenand.base == NULL) {
-		r = -ENOMEM;
-		goto err_release_mem_region;
-	}
 
-	if (pdata->onenand_setup != NULL) {
-		r = pdata->onenand_setup(c->onenand.base, &c->freq);
-		if (r < 0) {
-			dev_err(&pdev->dev, "Onenand platform setup failed: "
-				"%d\n", r);
-			goto err_iounmap;
-		}
-		c->setup = pdata->onenand_setup;
-	}
+	mem_size = resource_size(res);
+	if (!devm_request_mem_region(dev, c->phys_base, mem_size,
+				     dev->driver->name)) {
 
-	if (c->gpio_irq) {
-		if ((r = gpio_request(c->gpio_irq, "OneNAND irq")) < 0) {
-			dev_err(&pdev->dev,  "Failed to request GPIO%d for "
-				"OneNAND\n", c->gpio_irq);
-			goto err_iounmap;
+		dev_err(dev, "Cannot reserve memory region at 0x%08lx, size: 0x%x\n",
+			c->phys_base, mem_size);
+		return -EBUSY;
 	}
-	gpio_direction_input(c->gpio_irq);
 
-	if ((r = request_irq(gpio_to_irq(c->gpio_irq),
-			     omap2_onenand_interrupt, IRQF_TRIGGER_RISING,
-			     pdev->dev.driver->name, c)) < 0)
-		goto err_release_gpio;
+	c->onenand.base = devm_ioremap(dev, c->phys_base, mem_size);
+	if (!c->onenand.base)
+		return -ENOMEM;
+
+	if (!of_property_read_u32(np, "dma-channel", &val)) {
+		c->dma_channel = val;
+		r = omap_request_dma(0, dev->driver->name,
+					omap2_onenand_dma_cb, (void *)c,
+					&c->dma_channel);
+		if (r) {
+			dev_info(dev, "failed to allocate DMA, using PIO\n");
+			c->dma_channel = -1;
+		}
 	}
 
 	if (c->dma_channel >= 0) {
-		r = omap_request_dma(0, pdev->dev.driver->name,
-				     omap2_onenand_dma_cb, (void *) c,
-				     &c->dma_channel);
-		if (r == 0) {
-			omap_set_dma_write_mode(c->dma_channel,
-						OMAP_DMA_WRITE_NON_POSTED);
-			omap_set_dma_src_data_pack(c->dma_channel, 1);
-			omap_set_dma_src_burst_mode(c->dma_channel,
-						    OMAP_DMA_DATA_BURST_8);
-			omap_set_dma_dest_data_pack(c->dma_channel, 1);
-			omap_set_dma_dest_burst_mode(c->dma_channel,
-						     OMAP_DMA_DATA_BURST_8);
-		} else {
-			dev_info(&pdev->dev,
-				 "failed to allocate DMA for OneNAND, "
-				 "using PIO instead\n");
-			c->dma_channel = -1;
+		c->onenand.wait = omap2_onenand_wait;
+		c->onenand.read_bufferram = omap2_onenand_read_bufferram;
+		c->onenand.write_bufferram = omap2_onenand_write_bufferram;
+
+		c->gpiod = devm_gpiod_get(dev, "OneNAND irq", GPIOD_IN);
+		if (IS_ERR(c->gpiod)) {
+			r = PTR_ERR(c->gpiod);
+			/* Just try again if this happens */
+			if (r != -EPROBE_DEFER)
+				dev_err(dev, "error getting gpio: %d\n", r);
+			goto err_release_dma;
 		}
+		r = devm_request_irq(dev, gpiod_to_irq(c->gpiod),
+				omap2_onenand_interrupt, IRQF_TRIGGER_RISING,
+				"OneNAND irq", c);
+		if (r)
+			goto err_release_dma;
+
+		omap_set_dma_write_mode(c->dma_channel,
+					OMAP_DMA_WRITE_NON_POSTED);
+		omap_set_dma_src_data_pack(c->dma_channel, 1);
+		omap_set_dma_src_burst_mode(c->dma_channel,
+					    OMAP_DMA_DATA_BURST_8);
+		omap_set_dma_dest_data_pack(c->dma_channel, 1);
+		omap_set_dma_dest_burst_mode(c->dma_channel,
+					     OMAP_DMA_DATA_BURST_8);
 	}
 
-	dev_info(&pdev->dev, "initializing on CS%d, phys base 0x%08lx, virtual "
-		 "base %p, freq %d MHz\n", c->gpmc_cs, c->phys_base,
-		 c->onenand.base, c->freq);
+	dev_info(dev,
+		 "initializing on CS%d, phys base 0x%08lx, virtual base %p\n",
+		 c->gpmc_cs, c->phys_base, c->onenand.base);
 
 	c->pdev = pdev;
 	c->mtd.priv = &c->onenand;
-
-	c->mtd.dev.parent = &pdev->dev;
-	mtd_set_of_node(&c->mtd, pdata->of_node);
-
-	this = &c->onenand;
-	if (c->dma_channel >= 0) {
-		this->wait = omap2_onenand_wait;
-		this->read_bufferram = omap2_onenand_read_bufferram;
-		this->write_bufferram = omap2_onenand_write_bufferram;
-	}
+	c->mtd.dev.parent = dev;
+	mtd_set_of_node(&c->mtd, dev->of_node);
 
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
 		goto err_release_dma;
 
+	freq = omap2_onenand_get_freq(c->onenand.version_id);
+	if (freq > 0) {
+		switch (freq) {
+		case 104:
+			latency = 7;
+			break;
+		case 83:
+			latency = 6;
+			break;
+		case 66:
+			latency = 5;
+			break;
+		case 56:
+			latency = 4;
+			break;
+		default:	/* 40 MHz or lower */
+			latency = 3;
+			break;
+		}
+
+		r = gpmc_omap_onenand_set_timings(dev, c->gpmc_cs,
+						  freq, latency, &info);
+		if (r)
+			goto err_release_onenand;
+
+		r = omap2_onenand_set_cfg(c, info.sync_read, info.sync_write,
+					  latency, info.burst_len);
+		if (r)
+			goto err_release_onenand;
+
+		if (info.sync_read || info.sync_write)
+			dev_info(dev, "optimized timings for %d MHz\n", freq);
+	}
+
 	r = mtd_device_register(&c->mtd, NULL, 0);
 	if (r)
 		goto err_release_onenand;
@@ -568,17 +635,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 err_release_dma:
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
-	if (c->gpio_irq)
-		free_irq(gpio_to_irq(c->gpio_irq), c);
-err_release_gpio:
-	if (c->gpio_irq)
-		gpio_free(c->gpio_irq);
-err_iounmap:
-	iounmap(c->onenand.base);
-err_release_mem_region:
-	release_mem_region(c->phys_base, c->mem_size);
-err_kfree:
-	kfree(c);
 
 	return r;
 }
@@ -591,23 +647,23 @@ static int omap2_onenand_remove(struct platform_device *pdev)
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
 	omap2_onenand_shutdown(pdev);
-	if (c->gpio_irq) {
-		free_irq(gpio_to_irq(c->gpio_irq), c);
-		gpio_free(c->gpio_irq);
-	}
-	iounmap(c->onenand.base);
-	release_mem_region(c->phys_base, c->mem_size);
-	kfree(c);
 
 	return 0;
 }
 
+static const struct of_device_id omap2_onenand_id_table[] = {
+	{ .compatible = "ti,omap2-onenand", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, omap2_onenand_id_table);
+
 static struct platform_driver omap2_onenand_driver = {
 	.probe		= omap2_onenand_probe,
 	.remove		= omap2_onenand_remove,
 	.shutdown	= omap2_onenand_shutdown,
 	.driver		= {
 		.name	= DRIVER_NAME,
+		.of_match_table = omap2_onenand_id_table,
 	},
 };
 
-- 
2.11.0


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

[PATCH v3 7/7] mtd: onenand: omap2: Configure driver from DT

[Ladislav Michl]

Move away from platform data configuration and use pure DT approach.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
---
 Changes:
 -v2: move cleanups into separate patches
      simplify dma setup
      fix checkpatch error
      print info about otimized timings in sync mode only
 -v3: remove 'ti,omap3-onenand' compatible as it is not needed anymore

 drivers/mtd/onenand/omap2.c | 304 ++++++++++++++++++++++++++------------------
 1 file changed, 180 insertions(+), 124 deletions(-)

diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 13da0b8c418b..4a3fee84a5ac 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -28,16 +28,17 @@
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/onenand.h>
 #include <linux/mtd/partitions.h>
+#include <linux/of_device.h>
+#include <linux/omap-gpmc.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
 #include <linux/io.h>
 #include <linux/slab.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
 
 #include <asm/mach/flash.h>
-#include <linux/platform_data/mtd-onenand-omap2.h>
 
 #include <linux/omap-dma.h>
 
@@ -49,15 +50,12 @@ struct omap2_onenand {
 	struct platform_device *pdev;
 	int gpmc_cs;
 	unsigned long phys_base;
-	unsigned int mem_size;
-	int gpio_irq;
+	struct gpio_desc *gpiod;
 	struct mtd_info mtd;
 	struct onenand_chip onenand;
 	struct completion irq_done;
 	struct completion dma_done;
 	int dma_channel;
-	int freq;
-	int (*setup)(void __iomem *base, int *freq_ptr);
 };
 
 static void omap2_onenand_dma_cb(int lch, u16 ch_status, void *data)
@@ -87,6 +85,65 @@ static inline void write_reg(struct omap2_onenand *c, unsigned short value,
 	writew(value, c->onenand.base + reg);
 }
 
+static int omap2_onenand_set_cfg(struct omap2_onenand *c,
+				 bool sr, bool sw,
+				 int latency, int burst_len)
+{
+	unsigned short reg = ONENAND_SYS_CFG1_RDY | ONENAND_SYS_CFG1_INT;
+
+	reg |= latency << ONENAND_SYS_CFG1_BRL_SHIFT;
+
+	switch (burst_len) {
+	case 0:		/* continuous */
+		break;
+	case 4:
+		reg |= ONENAND_SYS_CFG1_BL_4;
+		break;
+	case 8:
+		reg |= ONENAND_SYS_CFG1_BL_8;
+		break;
+	case 16:
+		reg |= ONENAND_SYS_CFG1_BL_16;
+		break;
+	case 32:
+		reg |= ONENAND_SYS_CFG1_BL_32;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	if (latency > 5)
+		reg |= ONENAND_SYS_CFG1_HF;
+	if (latency > 7)
+		reg |= ONENAND_SYS_CFG1_VHF;
+	if (sr)
+		reg |= ONENAND_SYS_CFG1_SYNC_READ;
+	if (sw)
+		reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
+
+	write_reg(c, reg, ONENAND_REG_SYS_CFG1);
+
+	return 0;
+}
+
+static int omap2_onenand_get_freq(int ver)
+{
+	switch ((ver >> 4) & 0xf) {
+	case 0:
+		return 40;
+	case 1:
+		return 54;
+	case 2:
+		return 66;
+	case 3:
+		return 83;
+	case 4:
+		return 104;
+	}
+
+	return -EINVAL;
+}
+
 static void wait_err(char *msg, int state, unsigned int ctrl, unsigned int intr)
 {
 	printk(KERN_ERR "onenand_wait: %s! state %d ctrl 0x%04x intr 0x%04x\n",
@@ -155,17 +212,13 @@ static int omap2_onenand_wait(struct mtd_info *mtd, int state)
 		}
 
 		reinit_completion(&c->irq_done);
-		if (c->gpio_irq) {
-			result = gpio_get_value(c->gpio_irq);
-			if (result == -1) {
-				ctrl = read_reg(c, ONENAND_REG_CTRL_STATUS);
-				intr = read_reg(c, ONENAND_REG_INTERRUPT);
-				wait_err("gpio error", state, ctrl, intr);
-				return -EIO;
-			}
-		} else
-			result = 0;
-		if (result == 0) {
+		result = c->gpiod ? gpiod_get_value(c->gpiod) : 0;
+		if (result < 0) {
+			ctrl = read_reg(c, ONENAND_REG_CTRL_STATUS);
+			intr = read_reg(c, ONENAND_REG_INTERRUPT);
+			wait_err("gpio error", state, ctrl, intr);
+			return result;
+		} else if (result == 0) {
 			int retry_cnt = 0;
 retry:
 			result = wait_for_completion_timeout(&c->irq_done,
@@ -426,8 +479,6 @@ static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
 	return 0;
 }
 
-static struct platform_driver omap2_onenand_driver;
-
 static void omap2_onenand_shutdown(struct platform_device *pdev)
 {
 	struct omap2_onenand *c = dev_get_drvdata(&pdev->dev);
@@ -441,120 +492,136 @@ static void omap2_onenand_shutdown(struct platform_device *pdev)
 
 static int omap2_onenand_probe(struct platform_device *pdev)
 {
-	struct omap_onenand_platform_data *pdata;
-	struct omap2_onenand *c;
-	struct onenand_chip *this;
-	int r;
+	u32 val;
+	int freq, latency, r;
+	unsigned int mem_size;
 	struct resource *res;
+	struct omap2_onenand *c;
+	struct gpmc_onenand_info info;
+	struct device *dev = &pdev->dev;
+	struct device_node *np = dev->of_node;
 
-	pdata = dev_get_platdata(&pdev->dev);
-	if (pdata == NULL) {
-		dev_err(&pdev->dev, "platform data missing\n");
-		return -ENODEV;
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "error getting memory resource\n");
+		return -EINVAL;
+	}
+
+	r = of_property_read_u32(np, "reg", &val);
+	if (r) {
+		dev_err(dev, "reg not found in DT\n");
+		return r;
 	}
 
-	c = kzalloc(sizeof(struct omap2_onenand), GFP_KERNEL);
+	c = devm_kzalloc(dev, sizeof(struct omap2_onenand), GFP_KERNEL);
 	if (!c)
 		return -ENOMEM;
 
 	init_completion(&c->irq_done);
 	init_completion(&c->dma_done);
-	c->gpmc_cs = pdata->cs;
-	c->gpio_irq = pdata->gpio_irq;
-	c->dma_channel = pdata->dma_channel;
-	if (c->dma_channel < 0) {
-		/* if -1, don't use DMA */
-		c->gpio_irq = 0;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL) {
-		r = -EINVAL;
-		dev_err(&pdev->dev, "error getting memory resource\n");
-		goto err_kfree;
-	}
-
+	c->gpmc_cs = val;
+	c->dma_channel = -1;
 	c->phys_base = res->start;
-	c->mem_size = resource_size(res);
-
-	if (request_mem_region(c->phys_base, c->mem_size,
-			       pdev->dev.driver->name) == NULL) {
-		dev_err(&pdev->dev, "Cannot reserve memory region at 0x%08lx, size: 0x%x\n",
-						c->phys_base, c->mem_size);
-		r = -EBUSY;
-		goto err_kfree;
-	}
-	c->onenand.base = ioremap(c->phys_base, c->mem_size);
-	if (c->onenand.base == NULL) {
-		r = -ENOMEM;
-		goto err_release_mem_region;
-	}
 
-	if (pdata->onenand_setup != NULL) {
-		r = pdata->onenand_setup(c->onenand.base, &c->freq);
-		if (r < 0) {
-			dev_err(&pdev->dev, "Onenand platform setup failed: "
-				"%d\n", r);
-			goto err_iounmap;
-		}
-		c->setup = pdata->onenand_setup;
-	}
+	mem_size = resource_size(res);
+	if (!devm_request_mem_region(dev, c->phys_base, mem_size,
+				     dev->driver->name)) {
 
-	if (c->gpio_irq) {
-		if ((r = gpio_request(c->gpio_irq, "OneNAND irq")) < 0) {
-			dev_err(&pdev->dev,  "Failed to request GPIO%d for "
-				"OneNAND\n", c->gpio_irq);
-			goto err_iounmap;
+		dev_err(dev, "Cannot reserve memory region at 0x%08lx, size: 0x%x\n",
+			c->phys_base, mem_size);
+		return -EBUSY;
 	}
-	gpio_direction_input(c->gpio_irq);
 
-	if ((r = request_irq(gpio_to_irq(c->gpio_irq),
-			     omap2_onenand_interrupt, IRQF_TRIGGER_RISING,
-			     pdev->dev.driver->name, c)) < 0)
-		goto err_release_gpio;
+	c->onenand.base = devm_ioremap(dev, c->phys_base, mem_size);
+	if (!c->onenand.base)
+		return -ENOMEM;
+
+	if (!of_property_read_u32(np, "dma-channel", &val)) {
+		c->dma_channel = val;
+		r = omap_request_dma(0, dev->driver->name,
+					omap2_onenand_dma_cb, (void *)c,
+					&c->dma_channel);
+		if (r) {
+			dev_info(dev, "failed to allocate DMA, using PIO\n");
+			c->dma_channel = -1;
+		}
 	}
 
 	if (c->dma_channel >= 0) {
-		r = omap_request_dma(0, pdev->dev.driver->name,
-				     omap2_onenand_dma_cb, (void *) c,
-				     &c->dma_channel);
-		if (r == 0) {
-			omap_set_dma_write_mode(c->dma_channel,
-						OMAP_DMA_WRITE_NON_POSTED);
-			omap_set_dma_src_data_pack(c->dma_channel, 1);
-			omap_set_dma_src_burst_mode(c->dma_channel,
-						    OMAP_DMA_DATA_BURST_8);
-			omap_set_dma_dest_data_pack(c->dma_channel, 1);
-			omap_set_dma_dest_burst_mode(c->dma_channel,
-						     OMAP_DMA_DATA_BURST_8);
-		} else {
-			dev_info(&pdev->dev,
-				 "failed to allocate DMA for OneNAND, "
-				 "using PIO instead\n");
-			c->dma_channel = -1;
+		c->onenand.wait = omap2_onenand_wait;
+		c->onenand.read_bufferram = omap2_onenand_read_bufferram;
+		c->onenand.write_bufferram = omap2_onenand_write_bufferram;
+
+		c->gpiod = devm_gpiod_get(dev, "OneNAND irq", GPIOD_IN);
+		if (IS_ERR(c->gpiod)) {
+			r = PTR_ERR(c->gpiod);
+			/* Just try again if this happens */
+			if (r != -EPROBE_DEFER)
+				dev_err(dev, "error getting gpio: %d\n", r);
+			goto err_release_dma;
 		}
+		r = devm_request_irq(dev, gpiod_to_irq(c->gpiod),
+				omap2_onenand_interrupt, IRQF_TRIGGER_RISING,
+				"OneNAND irq", c);
+		if (r)
+			goto err_release_dma;
+
+		omap_set_dma_write_mode(c->dma_channel,
+					OMAP_DMA_WRITE_NON_POSTED);
+		omap_set_dma_src_data_pack(c->dma_channel, 1);
+		omap_set_dma_src_burst_mode(c->dma_channel,
+					    OMAP_DMA_DATA_BURST_8);
+		omap_set_dma_dest_data_pack(c->dma_channel, 1);
+		omap_set_dma_dest_burst_mode(c->dma_channel,
+					     OMAP_DMA_DATA_BURST_8);
 	}
 
-	dev_info(&pdev->dev, "initializing on CS%d, phys base 0x%08lx, virtual "
-		 "base %p, freq %d MHz\n", c->gpmc_cs, c->phys_base,
-		 c->onenand.base, c->freq);
+	dev_info(dev,
+		 "initializing on CS%d, phys base 0x%08lx, virtual base %p\n",
+		 c->gpmc_cs, c->phys_base, c->onenand.base);
 
 	c->pdev = pdev;
 	c->mtd.priv = &c->onenand;
-
-	c->mtd.dev.parent = &pdev->dev;
-	mtd_set_of_node(&c->mtd, pdata->of_node);
-
-	this = &c->onenand;
-	if (c->dma_channel >= 0) {
-		this->wait = omap2_onenand_wait;
-		this->read_bufferram = omap2_onenand_read_bufferram;
-		this->write_bufferram = omap2_onenand_write_bufferram;
-	}
+	c->mtd.dev.parent = dev;
+	mtd_set_of_node(&c->mtd, dev->of_node);
 
 	if ((r = onenand_scan(&c->mtd, 1)) < 0)
 		goto err_release_dma;
 
+	freq = omap2_onenand_get_freq(c->onenand.version_id);
+	if (freq > 0) {
+		switch (freq) {
+		case 104:
+			latency = 7;
+			break;
+		case 83:
+			latency = 6;
+			break;
+		case 66:
+			latency = 5;
+			break;
+		case 56:
+			latency = 4;
+			break;
+		default:	/* 40 MHz or lower */
+			latency = 3;
+			break;
+		}
+
+		r = gpmc_omap_onenand_set_timings(dev, c->gpmc_cs,
+						  freq, latency, &info);
+		if (r)
+			goto err_release_onenand;
+
+		r = omap2_onenand_set_cfg(c, info.sync_read, info.sync_write,
+					  latency, info.burst_len);
+		if (r)
+			goto err_release_onenand;
+
+		if (info.sync_read || info.sync_write)
+			dev_info(dev, "optimized timings for %d MHz\n", freq);
+	}
+
 	r = mtd_device_register(&c->mtd, NULL, 0);
 	if (r)
 		goto err_release_onenand;
@@ -568,17 +635,6 @@ static int omap2_onenand_probe(struct platform_device *pdev)
 err_release_dma:
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
-	if (c->gpio_irq)
-		free_irq(gpio_to_irq(c->gpio_irq), c);
-err_release_gpio:
-	if (c->gpio_irq)
-		gpio_free(c->gpio_irq);
-err_iounmap:
-	iounmap(c->onenand.base);
-err_release_mem_region:
-	release_mem_region(c->phys_base, c->mem_size);
-err_kfree:
-	kfree(c);
 
 	return r;
 }
@@ -591,23 +647,23 @@ static int omap2_onenand_remove(struct platform_device *pdev)
 	if (c->dma_channel != -1)
 		omap_free_dma(c->dma_channel);
 	omap2_onenand_shutdown(pdev);
-	if (c->gpio_irq) {
-		free_irq(gpio_to_irq(c->gpio_irq), c);
-		gpio_free(c->gpio_irq);
-	}
-	iounmap(c->onenand.base);
-	release_mem_region(c->phys_base, c->mem_size);
-	kfree(c);
 
 	return 0;
 }
 
+static const struct of_device_id omap2_onenand_id_table[] = {
+	{ .compatible = "ti,omap2-onenand", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, omap2_onenand_id_table);
+
 static struct platform_driver omap2_onenand_driver = {
 	.probe		= omap2_onenand_probe,
 	.remove		= omap2_onenand_remove,
 	.shutdown	= omap2_onenand_shutdown,
 	.driver		= {
 		.name	= DRIVER_NAME,
+		.of_match_table = omap2_onenand_id_table,
 	},
 };
 
-- 
2.11.0