* [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Hi,
As this series has cross dependency between omap and mtd subsystems,
I'll set up a immutable branch which omap-soc and l2-mtd must
merge in together to avoid any conflicts/breakage during integration.
Brian has acked all mtd patches. Tony needs to give his Ack for the
gpmc driver part and then I can provide the immutable branch.
Patches based on v4.6-rc1 and tested on:
dra-evm, am437x-gp-evm, beagleboard-c4, beagleboard-c4-legacyboot.
Summary:
We do a couple of things in this series which result in
cleaner device tree implementation, faster perfomance and
multi-platform support. As an added bonus we get to use the GPMC_WAIT
pins as GPI/Interrupts.
- Establish a custom interface between NAND and GPMC driver. This is
needed because all of the NAND registers sit in the GPMC register space.
- Clean up device tree support so that omap-gpmc IP and the omap2 NAND
driver can be used on non-OMAP platforms. e.g. Keystone.
- Implement GPIOCHIP for the GPMC WAITPINS. SoCs can contain
2 to 4 of these and most of them would be unused otherwise. It also
allows a cleaner implementation of NAND Ready pin status for the NAND driver.
- Implement GPMC IRQ domain to proivde the 2 NAND events and
GPMC WAITPIN edge interrupts.
- Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
On dra7-evm, Read speed increases from 13768 KiB/ to 17246 KiB/s.
Write speed was unchanged at 7123 KiB/s.
Changelog:
v6:
-addressed review comments.
-re-orderd patches so that functionality isn't broken at any point.
-rebased to v4.6-rc1.
v5:
-changed ready/busy# GPIO DT binding from "ready-gpio" to "rb-gpios".
-use irqdomain for gpmc NAND interrupts: fifoevent and termcount.
v4:
-Warn if using older incompatible DT i.e. compatible property not present
in nand node.
-Applied Tony's patch to fix broken ethernet on torpedo.
v3:
-Fixed and tested NAND using legacy boot on omap3-beagle.
-Support rising and falling edge interrupts on WAITpins.
-Update DT node of all gpmc users.
--
cheers,
-roger
Roger Quadros (17):
ARM: OMAP2+: gpmc: Add platform data
ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
memory: omap-gpmc: Introduce GPMC to NAND interface
memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
memory: omap-gpmc: Implement IRQ domain for NAND IRQs
mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers
mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty
check
mtd: nand: omap: Copy platform data parameters to omap_nand_info data
mtd: nand: omap: Clean up device tree support
mtd: nand: omap: Update DT binding documentation
memory: omap-gpmc: Prevent mapping into 1st 16MB
memory: omap-gpmc: Move device tree binding to correct location
memory: omap-gpmc: Support general purpose input for WAITPINs
memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
memory: omap-gpmc: Support WAIT pin edge interrupts
memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via
gpmc_regs
mtd: nand: omap2: Implement NAND ready using gpiolib
.../omap-gpmc.txt} | 17 +
.../devicetree/bindings/mtd/gpmc-nand.txt | 19 +-
arch/arm/mach-omap2/gpmc-nand.c | 7 +-
drivers/memory/Kconfig | 1 +
drivers/memory/omap-gpmc.c | 655 +++++++++++++--------
drivers/mtd/nand/omap2.c | 194 ++++--
include/linux/omap-gpmc.h | 172 +-----
.../{omap-gpmc.h => platform_data/gpmc-omap.h} | 101 ++--
include/linux/platform_data/mtd-nand-omap2.h | 12 +-
9 files changed, 679 insertions(+), 499 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} (89%)
copy include/linux/{omap-gpmc.h => platform_data/gpmc-omap.h} (71%)
--
2.5.0
^ permalink raw reply [flat|nested] 93+ messages in thread* [PATCH v6 01/17] ARM: OMAP2+: gpmc: Add platform data
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Add a platform data structure for GPMC. It contains all the necessary
platform information that needs to be passed from platform init code
to GPMC driver.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
include/linux/omap-gpmc.h | 3 +--
include/linux/platform_data/gpmc-omap.h | 30 ++++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 include/linux/platform_data/gpmc-omap.h
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index d833eb4..45d9075 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -7,8 +7,7 @@
* option) any later version.
*/
-/* Maximum Number of Chip Selects */
-#define GPMC_CS_NUM 8
+#include <linux/platform_data/gpmc-omap.h>
#define GPMC_CONFIG_WP 0x00000005
diff --git a/include/linux/platform_data/gpmc-omap.h b/include/linux/platform_data/gpmc-omap.h
new file mode 100644
index 0000000..6804a8b
--- /dev/null
+++ b/include/linux/platform_data/gpmc-omap.h
@@ -0,0 +1,30 @@
+/*
+ * OMAP GPMC Platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc. - http://www.ti.com
+ * Roger Quadros <rogerq@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef _GPMC_OMAP_H_
+#define _GPMC_OMAP_H_
+
+/* Maximum Number of Chip Selects */
+#define GPMC_CS_NUM 8
+
+/* Data for each chip select */
+struct gpmc_omap_cs_data {
+ bool valid; /* data is valid */
+ bool is_nand; /* device within this CS is NAND */
+ struct platform_device *pdev; /* device within this CS region */
+ unsigned int pdata_size;
+};
+
+struct gpmc_omap_platform_data {
+ struct gpmc_omap_cs_data cs[GPMC_CS_NUM];
+};
+
+#endif /* _GPMC_OMAP_H */
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 01/17] ARM: OMAP2+: gpmc: Add platform data
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Add a platform data structure for GPMC. It contains all the necessary
platform information that needs to be passed from platform init code
to GPMC driver.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
include/linux/omap-gpmc.h | 3 +--
include/linux/platform_data/gpmc-omap.h | 30 ++++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 include/linux/platform_data/gpmc-omap.h
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index d833eb4..45d9075 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -7,8 +7,7 @@
* option) any later version.
*/
-/* Maximum Number of Chip Selects */
-#define GPMC_CS_NUM 8
+#include <linux/platform_data/gpmc-omap.h>
#define GPMC_CONFIG_WP 0x00000005
diff --git a/include/linux/platform_data/gpmc-omap.h b/include/linux/platform_data/gpmc-omap.h
new file mode 100644
index 0000000..6804a8b
--- /dev/null
+++ b/include/linux/platform_data/gpmc-omap.h
@@ -0,0 +1,30 @@
+/*
+ * OMAP GPMC Platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc. - http://www.ti.com
+ * Roger Quadros <rogerq@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef _GPMC_OMAP_H_
+#define _GPMC_OMAP_H_
+
+/* Maximum Number of Chip Selects */
+#define GPMC_CS_NUM 8
+
+/* Data for each chip select */
+struct gpmc_omap_cs_data {
+ bool valid; /* data is valid */
+ bool is_nand; /* device within this CS is NAND */
+ struct platform_device *pdev; /* device within this CS region */
+ unsigned int pdata_size;
+};
+
+struct gpmc_omap_platform_data {
+ struct gpmc_omap_cs_data cs[GPMC_CS_NUM];
+};
+
+#endif /* _GPMC_OMAP_H */
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 02/17] ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Add device_timings, gpmc_timings and gpmc_setting to
gpmc platform data.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
include/linux/omap-gpmc.h | 139 -------------------------------
include/linux/platform_data/gpmc-omap.h | 142 ++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+), 139 deletions(-)
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 45d9075..2dcef1c 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -14,145 +14,6 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
-#define GPMC_BURST_4 4 /* 4 word burst */
-#define GPMC_BURST_8 8 /* 8 word burst */
-#define GPMC_BURST_16 16 /* 16 word burst */
-#define GPMC_DEVWIDTH_8BIT 1 /* 8-bit device width */
-#define GPMC_DEVWIDTH_16BIT 2 /* 16-bit device width */
-#define GPMC_MUX_AAD 1 /* Addr-Addr-Data multiplex */
-#define GPMC_MUX_AD 2 /* Addr-Data multiplex */
-
-/* bool type time settings */
-struct gpmc_bool_timings {
- bool cycle2cyclediffcsen;
- bool cycle2cyclesamecsen;
- bool we_extra_delay;
- bool oe_extra_delay;
- bool adv_extra_delay;
- bool cs_extra_delay;
- bool time_para_granularity;
-};
-
-/*
- * Note that all values in this struct are in nanoseconds except sync_clk
- * (which is in picoseconds), while the register values are in gpmc_fck cycles.
- */
-struct gpmc_timings {
- /* Minimum clock period for synchronous mode (in picoseconds) */
- u32 sync_clk;
-
- /* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
- u32 cs_on; /* Assertion time */
- u32 cs_rd_off; /* Read deassertion time */
- u32 cs_wr_off; /* Write deassertion time */
-
- /* ADV signal timings corresponding to GPMC_CONFIG3 */
- u32 adv_on; /* Assertion time */
- u32 adv_rd_off; /* Read deassertion time */
- u32 adv_wr_off; /* Write deassertion time */
- u32 adv_aad_mux_on; /* ADV assertion time for AAD */
- u32 adv_aad_mux_rd_off; /* ADV read deassertion time for AAD */
- u32 adv_aad_mux_wr_off; /* ADV write deassertion time for AAD */
-
- /* WE signals timings corresponding to GPMC_CONFIG4 */
- u32 we_on; /* WE assertion time */
- u32 we_off; /* WE deassertion time */
-
- /* OE signals timings corresponding to GPMC_CONFIG4 */
- u32 oe_on; /* OE assertion time */
- u32 oe_off; /* OE deassertion time */
- u32 oe_aad_mux_on; /* OE assertion time for AAD */
- u32 oe_aad_mux_off; /* OE deassertion time for AAD */
-
- /* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
- u32 page_burst_access; /* Multiple access word delay */
- u32 access; /* Start-cycle to first data valid delay */
- u32 rd_cycle; /* Total read cycle time */
- u32 wr_cycle; /* Total write cycle time */
-
- u32 bus_turnaround;
- u32 cycle2cycle_delay;
-
- u32 wait_monitoring;
- u32 clk_activation;
-
- /* The following are only on OMAP3430 */
- u32 wr_access; /* WRACCESSTIME */
- u32 wr_data_mux_bus; /* WRDATAONADMUXBUS */
-
- struct gpmc_bool_timings bool_timings;
-};
-
-/* Device timings in picoseconds */
-struct gpmc_device_timings {
- u32 t_ceasu; /* address setup to CS valid */
- u32 t_avdasu; /* address setup to ADV valid */
- /* XXX: try to combine t_avdp_r & t_avdp_w. Issue is
- * of tusb using these timings even for sync whilst
- * ideally for adv_rd/(wr)_off it should have considered
- * t_avdh instead. This indirectly necessitates r/w
- * variations of t_avdp as it is possible to have one
- * sync & other async
- */
- u32 t_avdp_r; /* ADV low time (what about t_cer ?) */
- u32 t_avdp_w;
- u32 t_aavdh; /* address hold time */
- u32 t_oeasu; /* address setup to OE valid */
- u32 t_aa; /* access time from ADV assertion */
- u32 t_iaa; /* initial access time */
- u32 t_oe; /* access time from OE assertion */
- u32 t_ce; /* access time from CS asertion */
- u32 t_rd_cycle; /* read cycle time */
- u32 t_cez_r; /* read CS deassertion to high Z */
- u32 t_cez_w; /* write CS deassertion to high Z */
- u32 t_oez; /* OE deassertion to high Z */
- u32 t_weasu; /* address setup to WE valid */
- u32 t_wpl; /* write assertion time */
- u32 t_wph; /* write deassertion time */
- u32 t_wr_cycle; /* write cycle time */
-
- u32 clk;
- u32 t_bacc; /* burst access valid clock to output delay */
- u32 t_ces; /* CS setup time to clk */
- u32 t_avds; /* ADV setup time to clk */
- u32 t_avdh; /* ADV hold time from clk */
- u32 t_ach; /* address hold time from clk */
- u32 t_rdyo; /* clk to ready valid */
-
- u32 t_ce_rdyz; /* XXX: description ?, or use t_cez instead */
- u32 t_ce_avd; /* CS on to ADV on delay */
-
- /* XXX: check the possibility of combining
- * cyc_aavhd_oe & cyc_aavdh_we
- */
- u8 cyc_aavdh_oe;/* read address hold time in cycles */
- u8 cyc_aavdh_we;/* write address hold time in cycles */
- u8 cyc_oe; /* access time from OE assertion in cycles */
- u8 cyc_wpl; /* write deassertion time in cycles */
- u32 cyc_iaa; /* initial access time in cycles */
-
- /* extra delays */
- bool ce_xdelay;
- bool avd_xdelay;
- bool oe_xdelay;
- bool we_xdelay;
-};
-
-struct gpmc_settings {
- bool burst_wrap; /* enables wrap bursting */
- bool burst_read; /* enables read page/burst mode */
- bool burst_write; /* enables write page/burst mode */
- bool device_nand; /* device is NAND */
- bool sync_read; /* enables synchronous reads */
- bool sync_write; /* enables synchronous writes */
- bool wait_on_read; /* monitor wait on reads */
- bool wait_on_write; /* monitor wait on writes */
- u32 burst_len; /* page/burst length */
- u32 device_width; /* device bus width (8 or 16 bit) */
- u32 mux_add_data; /* multiplex address & data */
- u32 wait_pin; /* wait-pin to be used */
-};
-
extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
struct gpmc_settings *gpmc_s,
struct gpmc_device_timings *dev_t);
diff --git a/include/linux/platform_data/gpmc-omap.h b/include/linux/platform_data/gpmc-omap.h
index 6804a8b..67ccdb0 100644
--- a/include/linux/platform_data/gpmc-omap.h
+++ b/include/linux/platform_data/gpmc-omap.h
@@ -15,10 +15,152 @@
/* Maximum Number of Chip Selects */
#define GPMC_CS_NUM 8
+/* bool type time settings */
+struct gpmc_bool_timings {
+ bool cycle2cyclediffcsen;
+ bool cycle2cyclesamecsen;
+ bool we_extra_delay;
+ bool oe_extra_delay;
+ bool adv_extra_delay;
+ bool cs_extra_delay;
+ bool time_para_granularity;
+};
+
+/*
+ * Note that all values in this struct are in nanoseconds except sync_clk
+ * (which is in picoseconds), while the register values are in gpmc_fck cycles.
+ */
+struct gpmc_timings {
+ /* Minimum clock period for synchronous mode (in picoseconds) */
+ u32 sync_clk;
+
+ /* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
+ u32 cs_on; /* Assertion time */
+ u32 cs_rd_off; /* Read deassertion time */
+ u32 cs_wr_off; /* Write deassertion time */
+
+ /* ADV signal timings corresponding to GPMC_CONFIG3 */
+ u32 adv_on; /* Assertion time */
+ u32 adv_rd_off; /* Read deassertion time */
+ u32 adv_wr_off; /* Write deassertion time */
+ u32 adv_aad_mux_on; /* ADV assertion time for AAD */
+ u32 adv_aad_mux_rd_off; /* ADV read deassertion time for AAD */
+ u32 adv_aad_mux_wr_off; /* ADV write deassertion time for AAD */
+
+ /* WE signals timings corresponding to GPMC_CONFIG4 */
+ u32 we_on; /* WE assertion time */
+ u32 we_off; /* WE deassertion time */
+
+ /* OE signals timings corresponding to GPMC_CONFIG4 */
+ u32 oe_on; /* OE assertion time */
+ u32 oe_off; /* OE deassertion time */
+ u32 oe_aad_mux_on; /* OE assertion time for AAD */
+ u32 oe_aad_mux_off; /* OE deassertion time for AAD */
+
+ /* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
+ u32 page_burst_access; /* Multiple access word delay */
+ u32 access; /* Start-cycle to first data valid delay */
+ u32 rd_cycle; /* Total read cycle time */
+ u32 wr_cycle; /* Total write cycle time */
+
+ u32 bus_turnaround;
+ u32 cycle2cycle_delay;
+
+ u32 wait_monitoring;
+ u32 clk_activation;
+
+ /* The following are only on OMAP3430 */
+ u32 wr_access; /* WRACCESSTIME */
+ u32 wr_data_mux_bus; /* WRDATAONADMUXBUS */
+
+ struct gpmc_bool_timings bool_timings;
+};
+
+/* Device timings in picoseconds */
+struct gpmc_device_timings {
+ u32 t_ceasu; /* address setup to CS valid */
+ u32 t_avdasu; /* address setup to ADV valid */
+ /* XXX: try to combine t_avdp_r & t_avdp_w. Issue is
+ * of tusb using these timings even for sync whilst
+ * ideally for adv_rd/(wr)_off it should have considered
+ * t_avdh instead. This indirectly necessitates r/w
+ * variations of t_avdp as it is possible to have one
+ * sync & other async
+ */
+ u32 t_avdp_r; /* ADV low time (what about t_cer ?) */
+ u32 t_avdp_w;
+ u32 t_aavdh; /* address hold time */
+ u32 t_oeasu; /* address setup to OE valid */
+ u32 t_aa; /* access time from ADV assertion */
+ u32 t_iaa; /* initial access time */
+ u32 t_oe; /* access time from OE assertion */
+ u32 t_ce; /* access time from CS asertion */
+ u32 t_rd_cycle; /* read cycle time */
+ u32 t_cez_r; /* read CS deassertion to high Z */
+ u32 t_cez_w; /* write CS deassertion to high Z */
+ u32 t_oez; /* OE deassertion to high Z */
+ u32 t_weasu; /* address setup to WE valid */
+ u32 t_wpl; /* write assertion time */
+ u32 t_wph; /* write deassertion time */
+ u32 t_wr_cycle; /* write cycle time */
+
+ u32 clk;
+ u32 t_bacc; /* burst access valid clock to output delay */
+ u32 t_ces; /* CS setup time to clk */
+ u32 t_avds; /* ADV setup time to clk */
+ u32 t_avdh; /* ADV hold time from clk */
+ u32 t_ach; /* address hold time from clk */
+ u32 t_rdyo; /* clk to ready valid */
+
+ u32 t_ce_rdyz; /* XXX: description ?, or use t_cez instead */
+ u32 t_ce_avd; /* CS on to ADV on delay */
+
+ /* XXX: check the possibility of combining
+ * cyc_aavhd_oe & cyc_aavdh_we
+ */
+ u8 cyc_aavdh_oe;/* read address hold time in cycles */
+ u8 cyc_aavdh_we;/* write address hold time in cycles */
+ u8 cyc_oe; /* access time from OE assertion in cycles */
+ u8 cyc_wpl; /* write deassertion time in cycles */
+ u32 cyc_iaa; /* initial access time in cycles */
+
+ /* extra delays */
+ bool ce_xdelay;
+ bool avd_xdelay;
+ bool oe_xdelay;
+ bool we_xdelay;
+};
+
+#define GPMC_BURST_4 4 /* 4 word burst */
+#define GPMC_BURST_8 8 /* 8 word burst */
+#define GPMC_BURST_16 16 /* 16 word burst */
+#define GPMC_DEVWIDTH_8BIT 1 /* 8-bit device width */
+#define GPMC_DEVWIDTH_16BIT 2 /* 16-bit device width */
+#define GPMC_MUX_AAD 1 /* Addr-Addr-Data multiplex */
+#define GPMC_MUX_AD 2 /* Addr-Data multiplex */
+
+struct gpmc_settings {
+ bool burst_wrap; /* enables wrap bursting */
+ bool burst_read; /* enables read page/burst mode */
+ bool burst_write; /* enables write page/burst mode */
+ bool device_nand; /* device is NAND */
+ bool sync_read; /* enables synchronous reads */
+ bool sync_write; /* enables synchronous writes */
+ bool wait_on_read; /* monitor wait on reads */
+ bool wait_on_write; /* monitor wait on writes */
+ u32 burst_len; /* page/burst length */
+ u32 device_width; /* device bus width (8 or 16 bit) */
+ u32 mux_add_data; /* multiplex address & data */
+ u32 wait_pin; /* wait-pin to be used */
+};
+
/* Data for each chip select */
struct gpmc_omap_cs_data {
bool valid; /* data is valid */
bool is_nand; /* device within this CS is NAND */
+ struct gpmc_settings *settings;
+ struct gpmc_device_timings *device_timings;
+ struct gpmc_timings *gpmc_timings;
struct platform_device *pdev; /* device within this CS region */
unsigned int pdata_size;
};
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 02/17] ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Add device_timings, gpmc_timings and gpmc_setting to
gpmc platform data.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
include/linux/omap-gpmc.h | 139 -------------------------------
include/linux/platform_data/gpmc-omap.h | 142 ++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+), 139 deletions(-)
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 45d9075..2dcef1c 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -14,145 +14,6 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
-#define GPMC_BURST_4 4 /* 4 word burst */
-#define GPMC_BURST_8 8 /* 8 word burst */
-#define GPMC_BURST_16 16 /* 16 word burst */
-#define GPMC_DEVWIDTH_8BIT 1 /* 8-bit device width */
-#define GPMC_DEVWIDTH_16BIT 2 /* 16-bit device width */
-#define GPMC_MUX_AAD 1 /* Addr-Addr-Data multiplex */
-#define GPMC_MUX_AD 2 /* Addr-Data multiplex */
-
-/* bool type time settings */
-struct gpmc_bool_timings {
- bool cycle2cyclediffcsen;
- bool cycle2cyclesamecsen;
- bool we_extra_delay;
- bool oe_extra_delay;
- bool adv_extra_delay;
- bool cs_extra_delay;
- bool time_para_granularity;
-};
-
-/*
- * Note that all values in this struct are in nanoseconds except sync_clk
- * (which is in picoseconds), while the register values are in gpmc_fck cycles.
- */
-struct gpmc_timings {
- /* Minimum clock period for synchronous mode (in picoseconds) */
- u32 sync_clk;
-
- /* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
- u32 cs_on; /* Assertion time */
- u32 cs_rd_off; /* Read deassertion time */
- u32 cs_wr_off; /* Write deassertion time */
-
- /* ADV signal timings corresponding to GPMC_CONFIG3 */
- u32 adv_on; /* Assertion time */
- u32 adv_rd_off; /* Read deassertion time */
- u32 adv_wr_off; /* Write deassertion time */
- u32 adv_aad_mux_on; /* ADV assertion time for AAD */
- u32 adv_aad_mux_rd_off; /* ADV read deassertion time for AAD */
- u32 adv_aad_mux_wr_off; /* ADV write deassertion time for AAD */
-
- /* WE signals timings corresponding to GPMC_CONFIG4 */
- u32 we_on; /* WE assertion time */
- u32 we_off; /* WE deassertion time */
-
- /* OE signals timings corresponding to GPMC_CONFIG4 */
- u32 oe_on; /* OE assertion time */
- u32 oe_off; /* OE deassertion time */
- u32 oe_aad_mux_on; /* OE assertion time for AAD */
- u32 oe_aad_mux_off; /* OE deassertion time for AAD */
-
- /* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
- u32 page_burst_access; /* Multiple access word delay */
- u32 access; /* Start-cycle to first data valid delay */
- u32 rd_cycle; /* Total read cycle time */
- u32 wr_cycle; /* Total write cycle time */
-
- u32 bus_turnaround;
- u32 cycle2cycle_delay;
-
- u32 wait_monitoring;
- u32 clk_activation;
-
- /* The following are only on OMAP3430 */
- u32 wr_access; /* WRACCESSTIME */
- u32 wr_data_mux_bus; /* WRDATAONADMUXBUS */
-
- struct gpmc_bool_timings bool_timings;
-};
-
-/* Device timings in picoseconds */
-struct gpmc_device_timings {
- u32 t_ceasu; /* address setup to CS valid */
- u32 t_avdasu; /* address setup to ADV valid */
- /* XXX: try to combine t_avdp_r & t_avdp_w. Issue is
- * of tusb using these timings even for sync whilst
- * ideally for adv_rd/(wr)_off it should have considered
- * t_avdh instead. This indirectly necessitates r/w
- * variations of t_avdp as it is possible to have one
- * sync & other async
- */
- u32 t_avdp_r; /* ADV low time (what about t_cer ?) */
- u32 t_avdp_w;
- u32 t_aavdh; /* address hold time */
- u32 t_oeasu; /* address setup to OE valid */
- u32 t_aa; /* access time from ADV assertion */
- u32 t_iaa; /* initial access time */
- u32 t_oe; /* access time from OE assertion */
- u32 t_ce; /* access time from CS asertion */
- u32 t_rd_cycle; /* read cycle time */
- u32 t_cez_r; /* read CS deassertion to high Z */
- u32 t_cez_w; /* write CS deassertion to high Z */
- u32 t_oez; /* OE deassertion to high Z */
- u32 t_weasu; /* address setup to WE valid */
- u32 t_wpl; /* write assertion time */
- u32 t_wph; /* write deassertion time */
- u32 t_wr_cycle; /* write cycle time */
-
- u32 clk;
- u32 t_bacc; /* burst access valid clock to output delay */
- u32 t_ces; /* CS setup time to clk */
- u32 t_avds; /* ADV setup time to clk */
- u32 t_avdh; /* ADV hold time from clk */
- u32 t_ach; /* address hold time from clk */
- u32 t_rdyo; /* clk to ready valid */
-
- u32 t_ce_rdyz; /* XXX: description ?, or use t_cez instead */
- u32 t_ce_avd; /* CS on to ADV on delay */
-
- /* XXX: check the possibility of combining
- * cyc_aavhd_oe & cyc_aavdh_we
- */
- u8 cyc_aavdh_oe;/* read address hold time in cycles */
- u8 cyc_aavdh_we;/* write address hold time in cycles */
- u8 cyc_oe; /* access time from OE assertion in cycles */
- u8 cyc_wpl; /* write deassertion time in cycles */
- u32 cyc_iaa; /* initial access time in cycles */
-
- /* extra delays */
- bool ce_xdelay;
- bool avd_xdelay;
- bool oe_xdelay;
- bool we_xdelay;
-};
-
-struct gpmc_settings {
- bool burst_wrap; /* enables wrap bursting */
- bool burst_read; /* enables read page/burst mode */
- bool burst_write; /* enables write page/burst mode */
- bool device_nand; /* device is NAND */
- bool sync_read; /* enables synchronous reads */
- bool sync_write; /* enables synchronous writes */
- bool wait_on_read; /* monitor wait on reads */
- bool wait_on_write; /* monitor wait on writes */
- u32 burst_len; /* page/burst length */
- u32 device_width; /* device bus width (8 or 16 bit) */
- u32 mux_add_data; /* multiplex address & data */
- u32 wait_pin; /* wait-pin to be used */
-};
-
extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
struct gpmc_settings *gpmc_s,
struct gpmc_device_timings *dev_t);
diff --git a/include/linux/platform_data/gpmc-omap.h b/include/linux/platform_data/gpmc-omap.h
index 6804a8b..67ccdb0 100644
--- a/include/linux/platform_data/gpmc-omap.h
+++ b/include/linux/platform_data/gpmc-omap.h
@@ -15,10 +15,152 @@
/* Maximum Number of Chip Selects */
#define GPMC_CS_NUM 8
+/* bool type time settings */
+struct gpmc_bool_timings {
+ bool cycle2cyclediffcsen;
+ bool cycle2cyclesamecsen;
+ bool we_extra_delay;
+ bool oe_extra_delay;
+ bool adv_extra_delay;
+ bool cs_extra_delay;
+ bool time_para_granularity;
+};
+
+/*
+ * Note that all values in this struct are in nanoseconds except sync_clk
+ * (which is in picoseconds), while the register values are in gpmc_fck cycles.
+ */
+struct gpmc_timings {
+ /* Minimum clock period for synchronous mode (in picoseconds) */
+ u32 sync_clk;
+
+ /* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
+ u32 cs_on; /* Assertion time */
+ u32 cs_rd_off; /* Read deassertion time */
+ u32 cs_wr_off; /* Write deassertion time */
+
+ /* ADV signal timings corresponding to GPMC_CONFIG3 */
+ u32 adv_on; /* Assertion time */
+ u32 adv_rd_off; /* Read deassertion time */
+ u32 adv_wr_off; /* Write deassertion time */
+ u32 adv_aad_mux_on; /* ADV assertion time for AAD */
+ u32 adv_aad_mux_rd_off; /* ADV read deassertion time for AAD */
+ u32 adv_aad_mux_wr_off; /* ADV write deassertion time for AAD */
+
+ /* WE signals timings corresponding to GPMC_CONFIG4 */
+ u32 we_on; /* WE assertion time */
+ u32 we_off; /* WE deassertion time */
+
+ /* OE signals timings corresponding to GPMC_CONFIG4 */
+ u32 oe_on; /* OE assertion time */
+ u32 oe_off; /* OE deassertion time */
+ u32 oe_aad_mux_on; /* OE assertion time for AAD */
+ u32 oe_aad_mux_off; /* OE deassertion time for AAD */
+
+ /* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
+ u32 page_burst_access; /* Multiple access word delay */
+ u32 access; /* Start-cycle to first data valid delay */
+ u32 rd_cycle; /* Total read cycle time */
+ u32 wr_cycle; /* Total write cycle time */
+
+ u32 bus_turnaround;
+ u32 cycle2cycle_delay;
+
+ u32 wait_monitoring;
+ u32 clk_activation;
+
+ /* The following are only on OMAP3430 */
+ u32 wr_access; /* WRACCESSTIME */
+ u32 wr_data_mux_bus; /* WRDATAONADMUXBUS */
+
+ struct gpmc_bool_timings bool_timings;
+};
+
+/* Device timings in picoseconds */
+struct gpmc_device_timings {
+ u32 t_ceasu; /* address setup to CS valid */
+ u32 t_avdasu; /* address setup to ADV valid */
+ /* XXX: try to combine t_avdp_r & t_avdp_w. Issue is
+ * of tusb using these timings even for sync whilst
+ * ideally for adv_rd/(wr)_off it should have considered
+ * t_avdh instead. This indirectly necessitates r/w
+ * variations of t_avdp as it is possible to have one
+ * sync & other async
+ */
+ u32 t_avdp_r; /* ADV low time (what about t_cer ?) */
+ u32 t_avdp_w;
+ u32 t_aavdh; /* address hold time */
+ u32 t_oeasu; /* address setup to OE valid */
+ u32 t_aa; /* access time from ADV assertion */
+ u32 t_iaa; /* initial access time */
+ u32 t_oe; /* access time from OE assertion */
+ u32 t_ce; /* access time from CS asertion */
+ u32 t_rd_cycle; /* read cycle time */
+ u32 t_cez_r; /* read CS deassertion to high Z */
+ u32 t_cez_w; /* write CS deassertion to high Z */
+ u32 t_oez; /* OE deassertion to high Z */
+ u32 t_weasu; /* address setup to WE valid */
+ u32 t_wpl; /* write assertion time */
+ u32 t_wph; /* write deassertion time */
+ u32 t_wr_cycle; /* write cycle time */
+
+ u32 clk;
+ u32 t_bacc; /* burst access valid clock to output delay */
+ u32 t_ces; /* CS setup time to clk */
+ u32 t_avds; /* ADV setup time to clk */
+ u32 t_avdh; /* ADV hold time from clk */
+ u32 t_ach; /* address hold time from clk */
+ u32 t_rdyo; /* clk to ready valid */
+
+ u32 t_ce_rdyz; /* XXX: description ?, or use t_cez instead */
+ u32 t_ce_avd; /* CS on to ADV on delay */
+
+ /* XXX: check the possibility of combining
+ * cyc_aavhd_oe & cyc_aavdh_we
+ */
+ u8 cyc_aavdh_oe;/* read address hold time in cycles */
+ u8 cyc_aavdh_we;/* write address hold time in cycles */
+ u8 cyc_oe; /* access time from OE assertion in cycles */
+ u8 cyc_wpl; /* write deassertion time in cycles */
+ u32 cyc_iaa; /* initial access time in cycles */
+
+ /* extra delays */
+ bool ce_xdelay;
+ bool avd_xdelay;
+ bool oe_xdelay;
+ bool we_xdelay;
+};
+
+#define GPMC_BURST_4 4 /* 4 word burst */
+#define GPMC_BURST_8 8 /* 8 word burst */
+#define GPMC_BURST_16 16 /* 16 word burst */
+#define GPMC_DEVWIDTH_8BIT 1 /* 8-bit device width */
+#define GPMC_DEVWIDTH_16BIT 2 /* 16-bit device width */
+#define GPMC_MUX_AAD 1 /* Addr-Addr-Data multiplex */
+#define GPMC_MUX_AD 2 /* Addr-Data multiplex */
+
+struct gpmc_settings {
+ bool burst_wrap; /* enables wrap bursting */
+ bool burst_read; /* enables read page/burst mode */
+ bool burst_write; /* enables write page/burst mode */
+ bool device_nand; /* device is NAND */
+ bool sync_read; /* enables synchronous reads */
+ bool sync_write; /* enables synchronous writes */
+ bool wait_on_read; /* monitor wait on reads */
+ bool wait_on_write; /* monitor wait on writes */
+ u32 burst_len; /* page/burst length */
+ u32 device_width; /* device bus width (8 or 16 bit) */
+ u32 mux_add_data; /* multiplex address & data */
+ u32 wait_pin; /* wait-pin to be used */
+};
+
/* Data for each chip select */
struct gpmc_omap_cs_data {
bool valid; /* data is valid */
bool is_nand; /* device within this CS is NAND */
+ struct gpmc_settings *settings;
+ struct gpmc_device_timings *device_timings;
+ struct gpmc_timings *gpmc_timings;
struct platform_device *pdev; /* device within this CS region */
unsigned int pdata_size;
};
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 03/17] memory: omap-gpmc: Introduce GPMC to NAND interface
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
The OMAP GPMC module has certain registers dedicated for NAND
access and some NAND bits mixed with other GPMC functionality.
For the NAND dedicated registers we have the struct gpmc_nand_regs.
The NAND driver needs to access NAND specific bits from the
following non-dedicated registers
- EMPTYWRITEBUFFERSTATUS from GPMC_STATUS
For accessing these bits we introduce the struct gpmc_nand_ops.
Add gpmc_omap_get_nand_ops() that returns the gpmc_nand_ops along
with updating the gpmc_nand_regs. This API will be called by the
OMAP NAND driver to access the necessary bits in GPMC register space.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 21 +++++++++++++++++++++
include/linux/omap-gpmc.h | 35 +++++++++++++++++++++++++++++++++--
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 21825dd..0b62afd 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1118,6 +1118,27 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
}
}
+static struct gpmc_nand_ops nand_ops;
+
+/**
+ * gpmc_omap_get_nand_ops - Get the GPMC NAND interface
+ * @regs: the GPMC NAND register map exclusive for NAND use.
+ * @cs: GPMC chip select number on which the NAND sits. The
+ * register map returned will be specific to this chip select.
+ *
+ * Returns NULL on error e.g. invalid cs.
+ */
+struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *reg, int cs)
+{
+ if (cs >= gpmc_cs_num)
+ return NULL;
+
+ gpmc_update_nand_reg(reg, cs);
+
+ return &nand_ops;
+}
+EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
+
int gpmc_get_client_irq(unsigned irq_config)
{
int i;
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 2dcef1c..dc2ada6 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -14,14 +14,45 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+/**
+ * gpmc_nand_ops - Interface between NAND and GPMC
+ * @nand_write_buffer_empty: get the NAND write buffer empty status.
+ */
+struct gpmc_nand_ops {
+ bool (*nand_writebuffer_empty)(void);
+};
+
+struct gpmc_nand_regs;
+
+#if IS_ENABLED(CONFIG_OMAP_GPMC)
+struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
+ int cs);
+#else
+static inline gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
+ int cs)
+{
+ return NULL;
+}
+#endif /* CONFIG_OMAP_GPMC */
+
+/*--------------------------------*/
+
+/* deprecated APIs */
+#if IS_ENABLED(CONFIG_OMAP_GPMC)
+void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
+#else
+static inline void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+{
+}
+#endif /* CONFIG_OMAP_GPMC */
+/*--------------------------------*/
+
extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
struct gpmc_settings *gpmc_s,
struct gpmc_device_timings *dev_t);
-struct gpmc_nand_regs;
struct device_node;
-extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 03/17] memory: omap-gpmc: Introduce GPMC to NAND interface
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: devicetree, nsekhar, linux-kernel, linux-mtd, ezequiel, javier,
linux-omap, dwmw2, fcooper, Roger Quadros
The OMAP GPMC module has certain registers dedicated for NAND
access and some NAND bits mixed with other GPMC functionality.
For the NAND dedicated registers we have the struct gpmc_nand_regs.
The NAND driver needs to access NAND specific bits from the
following non-dedicated registers
- EMPTYWRITEBUFFERSTATUS from GPMC_STATUS
For accessing these bits we introduce the struct gpmc_nand_ops.
Add gpmc_omap_get_nand_ops() that returns the gpmc_nand_ops along
with updating the gpmc_nand_regs. This API will be called by the
OMAP NAND driver to access the necessary bits in GPMC register space.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 21 +++++++++++++++++++++
include/linux/omap-gpmc.h | 35 +++++++++++++++++++++++++++++++++--
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 21825dd..0b62afd 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1118,6 +1118,27 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
}
}
+static struct gpmc_nand_ops nand_ops;
+
+/**
+ * gpmc_omap_get_nand_ops - Get the GPMC NAND interface
+ * @regs: the GPMC NAND register map exclusive for NAND use.
+ * @cs: GPMC chip select number on which the NAND sits. The
+ * register map returned will be specific to this chip select.
+ *
+ * Returns NULL on error e.g. invalid cs.
+ */
+struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *reg, int cs)
+{
+ if (cs >= gpmc_cs_num)
+ return NULL;
+
+ gpmc_update_nand_reg(reg, cs);
+
+ return &nand_ops;
+}
+EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
+
int gpmc_get_client_irq(unsigned irq_config)
{
int i;
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 2dcef1c..dc2ada6 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -14,14 +14,45 @@
#define GPMC_IRQ_FIFOEVENTENABLE 0x01
#define GPMC_IRQ_COUNT_EVENT 0x02
+/**
+ * gpmc_nand_ops - Interface between NAND and GPMC
+ * @nand_write_buffer_empty: get the NAND write buffer empty status.
+ */
+struct gpmc_nand_ops {
+ bool (*nand_writebuffer_empty)(void);
+};
+
+struct gpmc_nand_regs;
+
+#if IS_ENABLED(CONFIG_OMAP_GPMC)
+struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
+ int cs);
+#else
+static inline gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
+ int cs)
+{
+ return NULL;
+}
+#endif /* CONFIG_OMAP_GPMC */
+
+/*--------------------------------*/
+
+/* deprecated APIs */
+#if IS_ENABLED(CONFIG_OMAP_GPMC)
+void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
+#else
+static inline void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+{
+}
+#endif /* CONFIG_OMAP_GPMC */
+/*--------------------------------*/
+
extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
struct gpmc_settings *gpmc_s,
struct gpmc_device_timings *dev_t);
-struct gpmc_nand_regs;
struct device_node;
-extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
extern int gpmc_get_client_irq(unsigned irq_config);
extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
--
2.5.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 04/17] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
This is needed by OMAP NAND driver to poll the empty status
of the writebuffer.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 0b62afd..90dfba5 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -81,6 +81,8 @@
#define GPMC_CONFIG_LIMITEDADDRESS BIT(1)
+#define GPMC_STATUS_EMPTYWRITEBUFFERSTATUS BIT(0)
+
#define GPMC_CONFIG2_CSEXTRADELAY BIT(7)
#define GPMC_CONFIG3_ADVEXTRADELAY BIT(7)
#define GPMC_CONFIG4_OEEXTRADELAY BIT(7)
@@ -1118,7 +1120,17 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
}
}
-static struct gpmc_nand_ops nand_ops;
+static bool gpmc_nand_writebuffer_empty(void)
+{
+ if (gpmc_read_reg(GPMC_STATUS) & GPMC_STATUS_EMPTYWRITEBUFFERSTATUS)
+ return true;
+
+ return false;
+}
+
+static struct gpmc_nand_ops nand_ops = {
+ .nand_writebuffer_empty = gpmc_nand_writebuffer_empty,
+};
/**
* gpmc_omap_get_nand_ops - Get the GPMC NAND interface
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 04/17] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: devicetree, nsekhar, linux-kernel, linux-mtd, ezequiel, javier,
linux-omap, dwmw2, fcooper, Roger Quadros
This is needed by OMAP NAND driver to poll the empty status
of the writebuffer.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 0b62afd..90dfba5 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -81,6 +81,8 @@
#define GPMC_CONFIG_LIMITEDADDRESS BIT(1)
+#define GPMC_STATUS_EMPTYWRITEBUFFERSTATUS BIT(0)
+
#define GPMC_CONFIG2_CSEXTRADELAY BIT(7)
#define GPMC_CONFIG3_ADVEXTRADELAY BIT(7)
#define GPMC_CONFIG4_OEEXTRADELAY BIT(7)
@@ -1118,7 +1120,17 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
}
}
-static struct gpmc_nand_ops nand_ops;
+static bool gpmc_nand_writebuffer_empty(void)
+{
+ if (gpmc_read_reg(GPMC_STATUS) & GPMC_STATUS_EMPTYWRITEBUFFERSTATUS)
+ return true;
+
+ return false;
+}
+
+static struct gpmc_nand_ops nand_ops = {
+ .nand_writebuffer_empty = gpmc_nand_writebuffer_empty,
+};
/**
* gpmc_omap_get_nand_ops - Get the GPMC NAND interface
--
2.5.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for NAND IRQs
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
GPMC provides 2 interrupts for NAND use. i.e. fifoevent and termcount.
Use IRQ domain for this. NAND device tree node can then
get the necessary interrupts by using gpmc as the interrupt parent.
Legacy boot uses gpmc_get_client_irq to get the
NAND interrupts from the GPMC IRQ domain.
Get rid of custom bitmasks and use IRQ domain for that
as well.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 8 +
drivers/memory/omap-gpmc.c | 246 ++++++++++++----------
include/linux/omap-gpmc.h | 5 +-
3 files changed, 144 insertions(+), 115 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 0168370..13f1378 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -32,6 +32,12 @@ Required properties:
bootloader) are used for the physical address decoding.
As this will change in the future, filling correct
values here is a requirement.
+ - interrupt-controller: The GPMC driver implements and interrupt controller for
+ the NAND events "fifoevent" and "termcount".
+ The interrupt number mapping is as follows
+ 0 - NAND_fifoevent
+ 1 - NAND_termcount
+ - interrupt-cells: Must be set to 2
Timing properties for child nodes. All are optional and default to 0.
@@ -130,6 +136,8 @@ Example for an AM33xx board:
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
+ interrupt-controller;
+ #interrupt-cells = <2>;
/* child nodes go here */
};
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 90dfba5..e28d6bc 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -22,6 +22,7 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/of_address.h>
@@ -127,7 +128,6 @@
#define GPMC_CONFIG_RDY_BSY 0x00000001
#define GPMC_CONFIG_DEV_SIZE 0x00000002
#define GPMC_CONFIG_DEV_TYPE 0x00000003
-#define GPMC_SET_IRQ_STATUS 0x00000004
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 << 31)
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 << 30)
@@ -176,8 +176,6 @@
#define GPMC_CONFIG_WRITEPROTECT 0x00000010
#define WR_RD_PIN_MONITORING 0x00600000
-#define GPMC_ENABLE_IRQ 0x0000000d
-
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
@@ -201,11 +199,6 @@ struct gpmc_cs_data {
struct resource mem;
};
-struct gpmc_client_irq {
- unsigned irq;
- u32 bitmask;
-};
-
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -233,9 +226,13 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
};
-static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
-static struct irq_chip gpmc_irq_chip;
-static int gpmc_irq_start;
+struct gpmc_device {
+ struct device *dev;
+ int irq;
+ struct irq_chip irq_chip;
+};
+
+static struct irq_domain *gpmc_irq_domain;
static struct resource gpmc_mem_root;
static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
@@ -243,8 +240,6 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
/* Define chip-selects as reserved by default until probe completes */
static unsigned int gpmc_cs_num = GPMC_CS_NUM;
static unsigned int gpmc_nr_waitpins;
-static struct device *gpmc_dev;
-static int gpmc_irq;
static resource_size_t phys_base, mem_size;
static unsigned gpmc_capability;
static void __iomem *gpmc_base;
@@ -1056,14 +1051,6 @@ int gpmc_configure(int cmd, int wval)
u32 regval;
switch (cmd) {
- case GPMC_ENABLE_IRQ:
- gpmc_write_reg(GPMC_IRQENABLE, wval);
- break;
-
- case GPMC_SET_IRQ_STATUS:
- gpmc_write_reg(GPMC_IRQSTATUS, wval);
- break;
-
case GPMC_CONFIG_WP:
regval = gpmc_read_reg(GPMC_CONFIG);
if (wval)
@@ -1153,85 +1140,97 @@ EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
int gpmc_get_client_irq(unsigned irq_config)
{
- int i;
-
- if (hweight32(irq_config) > 1)
+ if (!gpmc_irq_domain) {
+ pr_warn("%s called before GPMC IRQ domain available\n",
+ __func__);
return 0;
+ }
- for (i = 0; i < GPMC_NR_IRQ; i++)
- if (gpmc_client_irq[i].bitmask & irq_config)
- return gpmc_client_irq[i].irq;
+ if (irq_config >= GPMC_NR_IRQ)
+ return 0;
- return 0;
+ return irq_create_mapping(gpmc_irq_domain, irq_config);
}
-static int gpmc_irq_endis(unsigned irq, bool endis)
+static int gpmc_irq_endis(unsigned long hwirq, bool endis)
{
- int i;
u32 regval;
- for (i = 0; i < GPMC_NR_IRQ; i++)
- if (irq == gpmc_client_irq[i].irq) {
- regval = gpmc_read_reg(GPMC_IRQENABLE);
- if (endis)
- regval |= gpmc_client_irq[i].bitmask;
- else
- regval &= ~gpmc_client_irq[i].bitmask;
- gpmc_write_reg(GPMC_IRQENABLE, regval);
- break;
- }
+ regval = gpmc_read_reg(GPMC_IRQENABLE);
+ if (endis)
+ regval |= BIT(hwirq);
+ else
+ regval &= ~BIT(hwirq);
+ gpmc_write_reg(GPMC_IRQENABLE, regval);
return 0;
}
static void gpmc_irq_disable(struct irq_data *p)
{
- gpmc_irq_endis(p->irq, false);
+ gpmc_irq_endis(p->hwirq, false);
}
static void gpmc_irq_enable(struct irq_data *p)
{
- gpmc_irq_endis(p->irq, true);
+ gpmc_irq_endis(p->hwirq, true);
}
static void gpmc_irq_noop(struct irq_data *data) { }
static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
-static int gpmc_setup_irq(void)
+static int gpmc_irq_map(struct irq_domain *d, unsigned int virq,
+ irq_hw_number_t hw)
{
- int i;
+ struct gpmc_device *gpmc = d->host_data;
+
+ irq_set_chip_data(virq, gpmc);
+ irq_set_chip_and_handler(virq, &gpmc->irq_chip, handle_simple_irq);
+ irq_modify_status(virq, IRQ_NOREQUEST, IRQ_NOAUTOEN);
+
+ return 0;
+}
+
+static const struct irq_domain_ops gpmc_irq_domain_ops = {
+ .map = gpmc_irq_map,
+ .xlate = irq_domain_xlate_twocell,
+};
+
+static irqreturn_t gpmc_handle_irq(int irq, void *data)
+{
+ int hwirq, virq;
u32 regval;
+ struct gpmc_device *gpmc = data;
- if (!gpmc_irq)
- return -EINVAL;
+ regval = gpmc_read_reg(GPMC_IRQSTATUS);
- gpmc_irq_start = irq_alloc_descs(-1, 0, GPMC_NR_IRQ, 0);
- if (gpmc_irq_start < 0) {
- pr_err("irq_alloc_descs failed\n");
- return gpmc_irq_start;
- }
+ if (!regval)
+ return IRQ_NONE;
- gpmc_irq_chip.name = "gpmc";
- gpmc_irq_chip.irq_startup = gpmc_irq_noop_ret;
- gpmc_irq_chip.irq_enable = gpmc_irq_enable;
- gpmc_irq_chip.irq_disable = gpmc_irq_disable;
- gpmc_irq_chip.irq_shutdown = gpmc_irq_noop;
- gpmc_irq_chip.irq_ack = gpmc_irq_noop;
- gpmc_irq_chip.irq_mask = gpmc_irq_noop;
- gpmc_irq_chip.irq_unmask = gpmc_irq_noop;
-
- gpmc_client_irq[0].bitmask = GPMC_IRQ_FIFOEVENTENABLE;
- gpmc_client_irq[1].bitmask = GPMC_IRQ_COUNT_EVENT;
-
- for (i = 0; i < GPMC_NR_IRQ; i++) {
- gpmc_client_irq[i].irq = gpmc_irq_start + i;
- irq_set_chip_and_handler(gpmc_client_irq[i].irq,
- &gpmc_irq_chip, handle_simple_irq);
- irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
- IRQ_NOAUTOEN);
+ for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++) {
+ if (regval & BIT(hwirq)) {
+ virq = irq_find_mapping(gpmc_irq_domain, hwirq);
+ if (!virq) {
+ dev_warn(gpmc->dev,
+ "spurious irq detected hwirq %d, virq %d\n",
+ hwirq, virq);
+ }
+
+ generic_handle_irq(virq);
+ }
}
+ gpmc_write_reg(GPMC_IRQSTATUS, regval);
+
+ return IRQ_HANDLED;
+}
+
+static int gpmc_setup_irq(struct gpmc_device *gpmc)
+{
+ u32 regval;
+ int rc;
+
/* Disable interrupts */
gpmc_write_reg(GPMC_IRQENABLE, 0);
@@ -1239,22 +1238,46 @@ static int gpmc_setup_irq(void)
regval = gpmc_read_reg(GPMC_IRQSTATUS);
gpmc_write_reg(GPMC_IRQSTATUS, regval);
- return request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
+ gpmc->irq_chip.name = "gpmc";
+ gpmc->irq_chip.irq_startup = gpmc_irq_noop_ret;
+ gpmc->irq_chip.irq_enable = gpmc_irq_enable;
+ gpmc->irq_chip.irq_disable = gpmc_irq_disable;
+ gpmc->irq_chip.irq_shutdown = gpmc_irq_noop;
+ gpmc->irq_chip.irq_ack = gpmc_irq_noop;
+ gpmc->irq_chip.irq_mask = gpmc_irq_noop;
+ gpmc->irq_chip.irq_unmask = gpmc_irq_noop;
+
+ gpmc_irq_domain = irq_domain_add_linear(gpmc->dev->of_node,
+ GPMC_NR_IRQ,
+ &gpmc_irq_domain_ops,
+ gpmc);
+ if (!gpmc_irq_domain) {
+ dev_err(gpmc->dev, "IRQ domain add failed\n");
+ return -ENODEV;
+ }
+
+ rc = request_irq(gpmc->irq, gpmc_handle_irq, 0, "gpmc", gpmc);
+ if (rc) {
+ dev_err(gpmc->dev, "failed to request irq %d: %d\n",
+ gpmc->irq, rc);
+ irq_domain_remove(gpmc_irq_domain);
+ gpmc_irq_domain = NULL;
+ }
+
+ return rc;
}
-static int gpmc_free_irq(void)
+static int gpmc_free_irq(struct gpmc_device *gpmc)
{
- int i;
+ int hwirq;
- if (gpmc_irq)
- free_irq(gpmc_irq, NULL);
+ free_irq(gpmc->irq, gpmc);
- for (i = 0; i < GPMC_NR_IRQ; i++) {
- irq_set_handler(gpmc_client_irq[i].irq, NULL);
- irq_set_chip(gpmc_client_irq[i].irq, &no_irq_chip);
- }
+ for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++)
+ irq_dispose_mapping(irq_find_mapping(gpmc_irq_domain, hwirq));
- irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+ irq_domain_remove(gpmc_irq_domain);
+ gpmc_irq_domain = NULL;
return 0;
}
@@ -2154,6 +2177,14 @@ static int gpmc_probe(struct platform_device *pdev)
int rc;
u32 l;
struct resource *res;
+ struct gpmc_device *gpmc;
+
+ gpmc = devm_kzalloc(&pdev->dev, sizeof(*gpmc), GFP_KERNEL);
+ if (!gpmc)
+ return -ENOMEM;
+
+ gpmc->dev = &pdev->dev;
+ platform_set_drvdata(pdev, gpmc);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
@@ -2167,15 +2198,16 @@ static int gpmc_probe(struct platform_device *pdev)
return PTR_ERR(gpmc_base);
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res == NULL)
- dev_warn(&pdev->dev, "Failed to get resource: irq\n");
- else
- gpmc_irq = res->start;
+ if (!res) {
+ dev_err(&pdev->dev, "Failed to get resource: irq\n");
+ return -ENOENT;
+ }
+
+ gpmc->irq = res->start;
gpmc_l3_clk = devm_clk_get(&pdev->dev, "fck");
if (IS_ERR(gpmc_l3_clk)) {
dev_err(&pdev->dev, "Failed to get GPMC fck\n");
- gpmc_irq = 0;
return PTR_ERR(gpmc_l3_clk);
}
@@ -2187,8 +2219,6 @@ static int gpmc_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
- gpmc_dev = &pdev->dev;
-
l = gpmc_read_reg(GPMC_REVISION);
/*
@@ -2207,13 +2237,16 @@ static int gpmc_probe(struct platform_device *pdev)
gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;
if (GPMC_REVISION_MAJOR(l) > 0x5)
gpmc_capability |= GPMC_HAS_MUX_AAD;
- dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
+ dev_info(gpmc->dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
gpmc_mem_init();
- if (gpmc_setup_irq() < 0)
- dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
+ rc = gpmc_setup_irq(gpmc);
+ if (rc) {
+ dev_err(gpmc->dev, "gpmc_setup_irq failed\n");
+ goto fail;
+ }
if (!pdev->dev.of_node) {
gpmc_cs_num = GPMC_CS_NUM;
@@ -2222,21 +2255,27 @@ static int gpmc_probe(struct platform_device *pdev)
rc = gpmc_probe_dt(pdev);
if (rc < 0) {
- pm_runtime_put_sync(&pdev->dev);
- dev_err(gpmc_dev, "failed to probe DT parameters\n");
- return rc;
+ dev_err(gpmc->dev, "failed to probe DT parameters\n");
+ gpmc_free_irq(gpmc);
+ goto fail;
}
return 0;
+
+fail:
+ pm_runtime_put_sync(&pdev->dev);
+ return rc;
}
static int gpmc_remove(struct platform_device *pdev)
{
- gpmc_free_irq();
+ struct gpmc_device *gpmc = platform_get_drvdata(pdev);
+
+ gpmc_free_irq(gpmc);
gpmc_mem_exit();
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
- gpmc_dev = NULL;
+
return 0;
}
@@ -2282,25 +2321,6 @@ static __exit void gpmc_exit(void)
postcore_initcall(gpmc_init);
module_exit(gpmc_exit);
-static irqreturn_t gpmc_handle_irq(int irq, void *dev)
-{
- int i;
- u32 regval;
-
- regval = gpmc_read_reg(GPMC_IRQSTATUS);
-
- if (!regval)
- return IRQ_NONE;
-
- for (i = 0; i < GPMC_NR_IRQ; i++)
- if (regval & gpmc_client_irq[i].bitmask)
- generic_handle_irq(gpmc_client_irq[i].irq);
-
- gpmc_write_reg(GPMC_IRQSTATUS, regval);
-
- return IRQ_HANDLED;
-}
-
static struct omap3_gpmc_regs gpmc_context;
void omap3_gpmc_save_context(void)
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index dc2ada6..9e9d79e 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -11,8 +11,9 @@
#define GPMC_CONFIG_WP 0x00000005
-#define GPMC_IRQ_FIFOEVENTENABLE 0x01
-#define GPMC_IRQ_COUNT_EVENT 0x02
+/* IRQ numbers in GPMC IRQ domain for legacy boot use */
+#define GPMC_IRQ_FIFOEVENTENABLE 0
+#define GPMC_IRQ_COUNT_EVENT 1
/**
* gpmc_nand_ops - Interface between NAND and GPMC
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for NAND IRQs
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
GPMC provides 2 interrupts for NAND use. i.e. fifoevent and termcount.
Use IRQ domain for this. NAND device tree node can then
get the necessary interrupts by using gpmc as the interrupt parent.
Legacy boot uses gpmc_get_client_irq to get the
NAND interrupts from the GPMC IRQ domain.
Get rid of custom bitmasks and use IRQ domain for that
as well.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 8 +
drivers/memory/omap-gpmc.c | 246 ++++++++++++----------
include/linux/omap-gpmc.h | 5 +-
3 files changed, 144 insertions(+), 115 deletions(-)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 0168370..13f1378 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -32,6 +32,12 @@ Required properties:
bootloader) are used for the physical address decoding.
As this will change in the future, filling correct
values here is a requirement.
+ - interrupt-controller: The GPMC driver implements and interrupt controller for
+ the NAND events "fifoevent" and "termcount".
+ The interrupt number mapping is as follows
+ 0 - NAND_fifoevent
+ 1 - NAND_termcount
+ - interrupt-cells: Must be set to 2
Timing properties for child nodes. All are optional and default to 0.
@@ -130,6 +136,8 @@ Example for an AM33xx board:
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
+ interrupt-controller;
+ #interrupt-cells = <2>;
/* child nodes go here */
};
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 90dfba5..e28d6bc 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -22,6 +22,7 @@
#include <linux/io.h>
#include <linux/module.h>
#include <linux/interrupt.h>
+#include <linux/irqdomain.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/of_address.h>
@@ -127,7 +128,6 @@
#define GPMC_CONFIG_RDY_BSY 0x00000001
#define GPMC_CONFIG_DEV_SIZE 0x00000002
#define GPMC_CONFIG_DEV_TYPE 0x00000003
-#define GPMC_SET_IRQ_STATUS 0x00000004
#define GPMC_CONFIG1_WRAPBURST_SUPP (1 << 31)
#define GPMC_CONFIG1_READMULTIPLE_SUPP (1 << 30)
@@ -176,8 +176,6 @@
#define GPMC_CONFIG_WRITEPROTECT 0x00000010
#define WR_RD_PIN_MONITORING 0x00600000
-#define GPMC_ENABLE_IRQ 0x0000000d
-
/* ECC commands */
#define GPMC_ECC_READ 0 /* Reset Hardware ECC for read */
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
@@ -201,11 +199,6 @@ struct gpmc_cs_data {
struct resource mem;
};
-struct gpmc_client_irq {
- unsigned irq;
- u32 bitmask;
-};
-
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -233,9 +226,13 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
};
-static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
-static struct irq_chip gpmc_irq_chip;
-static int gpmc_irq_start;
+struct gpmc_device {
+ struct device *dev;
+ int irq;
+ struct irq_chip irq_chip;
+};
+
+static struct irq_domain *gpmc_irq_domain;
static struct resource gpmc_mem_root;
static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
@@ -243,8 +240,6 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
/* Define chip-selects as reserved by default until probe completes */
static unsigned int gpmc_cs_num = GPMC_CS_NUM;
static unsigned int gpmc_nr_waitpins;
-static struct device *gpmc_dev;
-static int gpmc_irq;
static resource_size_t phys_base, mem_size;
static unsigned gpmc_capability;
static void __iomem *gpmc_base;
@@ -1056,14 +1051,6 @@ int gpmc_configure(int cmd, int wval)
u32 regval;
switch (cmd) {
- case GPMC_ENABLE_IRQ:
- gpmc_write_reg(GPMC_IRQENABLE, wval);
- break;
-
- case GPMC_SET_IRQ_STATUS:
- gpmc_write_reg(GPMC_IRQSTATUS, wval);
- break;
-
case GPMC_CONFIG_WP:
regval = gpmc_read_reg(GPMC_CONFIG);
if (wval)
@@ -1153,85 +1140,97 @@ EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
int gpmc_get_client_irq(unsigned irq_config)
{
- int i;
-
- if (hweight32(irq_config) > 1)
+ if (!gpmc_irq_domain) {
+ pr_warn("%s called before GPMC IRQ domain available\n",
+ __func__);
return 0;
+ }
- for (i = 0; i < GPMC_NR_IRQ; i++)
- if (gpmc_client_irq[i].bitmask & irq_config)
- return gpmc_client_irq[i].irq;
+ if (irq_config >= GPMC_NR_IRQ)
+ return 0;
- return 0;
+ return irq_create_mapping(gpmc_irq_domain, irq_config);
}
-static int gpmc_irq_endis(unsigned irq, bool endis)
+static int gpmc_irq_endis(unsigned long hwirq, bool endis)
{
- int i;
u32 regval;
- for (i = 0; i < GPMC_NR_IRQ; i++)
- if (irq == gpmc_client_irq[i].irq) {
- regval = gpmc_read_reg(GPMC_IRQENABLE);
- if (endis)
- regval |= gpmc_client_irq[i].bitmask;
- else
- regval &= ~gpmc_client_irq[i].bitmask;
- gpmc_write_reg(GPMC_IRQENABLE, regval);
- break;
- }
+ regval = gpmc_read_reg(GPMC_IRQENABLE);
+ if (endis)
+ regval |= BIT(hwirq);
+ else
+ regval &= ~BIT(hwirq);
+ gpmc_write_reg(GPMC_IRQENABLE, regval);
return 0;
}
static void gpmc_irq_disable(struct irq_data *p)
{
- gpmc_irq_endis(p->irq, false);
+ gpmc_irq_endis(p->hwirq, false);
}
static void gpmc_irq_enable(struct irq_data *p)
{
- gpmc_irq_endis(p->irq, true);
+ gpmc_irq_endis(p->hwirq, true);
}
static void gpmc_irq_noop(struct irq_data *data) { }
static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
-static int gpmc_setup_irq(void)
+static int gpmc_irq_map(struct irq_domain *d, unsigned int virq,
+ irq_hw_number_t hw)
{
- int i;
+ struct gpmc_device *gpmc = d->host_data;
+
+ irq_set_chip_data(virq, gpmc);
+ irq_set_chip_and_handler(virq, &gpmc->irq_chip, handle_simple_irq);
+ irq_modify_status(virq, IRQ_NOREQUEST, IRQ_NOAUTOEN);
+
+ return 0;
+}
+
+static const struct irq_domain_ops gpmc_irq_domain_ops = {
+ .map = gpmc_irq_map,
+ .xlate = irq_domain_xlate_twocell,
+};
+
+static irqreturn_t gpmc_handle_irq(int irq, void *data)
+{
+ int hwirq, virq;
u32 regval;
+ struct gpmc_device *gpmc = data;
- if (!gpmc_irq)
- return -EINVAL;
+ regval = gpmc_read_reg(GPMC_IRQSTATUS);
- gpmc_irq_start = irq_alloc_descs(-1, 0, GPMC_NR_IRQ, 0);
- if (gpmc_irq_start < 0) {
- pr_err("irq_alloc_descs failed\n");
- return gpmc_irq_start;
- }
+ if (!regval)
+ return IRQ_NONE;
- gpmc_irq_chip.name = "gpmc";
- gpmc_irq_chip.irq_startup = gpmc_irq_noop_ret;
- gpmc_irq_chip.irq_enable = gpmc_irq_enable;
- gpmc_irq_chip.irq_disable = gpmc_irq_disable;
- gpmc_irq_chip.irq_shutdown = gpmc_irq_noop;
- gpmc_irq_chip.irq_ack = gpmc_irq_noop;
- gpmc_irq_chip.irq_mask = gpmc_irq_noop;
- gpmc_irq_chip.irq_unmask = gpmc_irq_noop;
-
- gpmc_client_irq[0].bitmask = GPMC_IRQ_FIFOEVENTENABLE;
- gpmc_client_irq[1].bitmask = GPMC_IRQ_COUNT_EVENT;
-
- for (i = 0; i < GPMC_NR_IRQ; i++) {
- gpmc_client_irq[i].irq = gpmc_irq_start + i;
- irq_set_chip_and_handler(gpmc_client_irq[i].irq,
- &gpmc_irq_chip, handle_simple_irq);
- irq_modify_status(gpmc_client_irq[i].irq, IRQ_NOREQUEST,
- IRQ_NOAUTOEN);
+ for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++) {
+ if (regval & BIT(hwirq)) {
+ virq = irq_find_mapping(gpmc_irq_domain, hwirq);
+ if (!virq) {
+ dev_warn(gpmc->dev,
+ "spurious irq detected hwirq %d, virq %d\n",
+ hwirq, virq);
+ }
+
+ generic_handle_irq(virq);
+ }
}
+ gpmc_write_reg(GPMC_IRQSTATUS, regval);
+
+ return IRQ_HANDLED;
+}
+
+static int gpmc_setup_irq(struct gpmc_device *gpmc)
+{
+ u32 regval;
+ int rc;
+
/* Disable interrupts */
gpmc_write_reg(GPMC_IRQENABLE, 0);
@@ -1239,22 +1238,46 @@ static int gpmc_setup_irq(void)
regval = gpmc_read_reg(GPMC_IRQSTATUS);
gpmc_write_reg(GPMC_IRQSTATUS, regval);
- return request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
+ gpmc->irq_chip.name = "gpmc";
+ gpmc->irq_chip.irq_startup = gpmc_irq_noop_ret;
+ gpmc->irq_chip.irq_enable = gpmc_irq_enable;
+ gpmc->irq_chip.irq_disable = gpmc_irq_disable;
+ gpmc->irq_chip.irq_shutdown = gpmc_irq_noop;
+ gpmc->irq_chip.irq_ack = gpmc_irq_noop;
+ gpmc->irq_chip.irq_mask = gpmc_irq_noop;
+ gpmc->irq_chip.irq_unmask = gpmc_irq_noop;
+
+ gpmc_irq_domain = irq_domain_add_linear(gpmc->dev->of_node,
+ GPMC_NR_IRQ,
+ &gpmc_irq_domain_ops,
+ gpmc);
+ if (!gpmc_irq_domain) {
+ dev_err(gpmc->dev, "IRQ domain add failed\n");
+ return -ENODEV;
+ }
+
+ rc = request_irq(gpmc->irq, gpmc_handle_irq, 0, "gpmc", gpmc);
+ if (rc) {
+ dev_err(gpmc->dev, "failed to request irq %d: %d\n",
+ gpmc->irq, rc);
+ irq_domain_remove(gpmc_irq_domain);
+ gpmc_irq_domain = NULL;
+ }
+
+ return rc;
}
-static int gpmc_free_irq(void)
+static int gpmc_free_irq(struct gpmc_device *gpmc)
{
- int i;
+ int hwirq;
- if (gpmc_irq)
- free_irq(gpmc_irq, NULL);
+ free_irq(gpmc->irq, gpmc);
- for (i = 0; i < GPMC_NR_IRQ; i++) {
- irq_set_handler(gpmc_client_irq[i].irq, NULL);
- irq_set_chip(gpmc_client_irq[i].irq, &no_irq_chip);
- }
+ for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++)
+ irq_dispose_mapping(irq_find_mapping(gpmc_irq_domain, hwirq));
- irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+ irq_domain_remove(gpmc_irq_domain);
+ gpmc_irq_domain = NULL;
return 0;
}
@@ -2154,6 +2177,14 @@ static int gpmc_probe(struct platform_device *pdev)
int rc;
u32 l;
struct resource *res;
+ struct gpmc_device *gpmc;
+
+ gpmc = devm_kzalloc(&pdev->dev, sizeof(*gpmc), GFP_KERNEL);
+ if (!gpmc)
+ return -ENOMEM;
+
+ gpmc->dev = &pdev->dev;
+ platform_set_drvdata(pdev, gpmc);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
@@ -2167,15 +2198,16 @@ static int gpmc_probe(struct platform_device *pdev)
return PTR_ERR(gpmc_base);
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res == NULL)
- dev_warn(&pdev->dev, "Failed to get resource: irq\n");
- else
- gpmc_irq = res->start;
+ if (!res) {
+ dev_err(&pdev->dev, "Failed to get resource: irq\n");
+ return -ENOENT;
+ }
+
+ gpmc->irq = res->start;
gpmc_l3_clk = devm_clk_get(&pdev->dev, "fck");
if (IS_ERR(gpmc_l3_clk)) {
dev_err(&pdev->dev, "Failed to get GPMC fck\n");
- gpmc_irq = 0;
return PTR_ERR(gpmc_l3_clk);
}
@@ -2187,8 +2219,6 @@ static int gpmc_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
- gpmc_dev = &pdev->dev;
-
l = gpmc_read_reg(GPMC_REVISION);
/*
@@ -2207,13 +2237,16 @@ static int gpmc_probe(struct platform_device *pdev)
gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;
if (GPMC_REVISION_MAJOR(l) > 0x5)
gpmc_capability |= GPMC_HAS_MUX_AAD;
- dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
+ dev_info(gpmc->dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
gpmc_mem_init();
- if (gpmc_setup_irq() < 0)
- dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
+ rc = gpmc_setup_irq(gpmc);
+ if (rc) {
+ dev_err(gpmc->dev, "gpmc_setup_irq failed\n");
+ goto fail;
+ }
if (!pdev->dev.of_node) {
gpmc_cs_num = GPMC_CS_NUM;
@@ -2222,21 +2255,27 @@ static int gpmc_probe(struct platform_device *pdev)
rc = gpmc_probe_dt(pdev);
if (rc < 0) {
- pm_runtime_put_sync(&pdev->dev);
- dev_err(gpmc_dev, "failed to probe DT parameters\n");
- return rc;
+ dev_err(gpmc->dev, "failed to probe DT parameters\n");
+ gpmc_free_irq(gpmc);
+ goto fail;
}
return 0;
+
+fail:
+ pm_runtime_put_sync(&pdev->dev);
+ return rc;
}
static int gpmc_remove(struct platform_device *pdev)
{
- gpmc_free_irq();
+ struct gpmc_device *gpmc = platform_get_drvdata(pdev);
+
+ gpmc_free_irq(gpmc);
gpmc_mem_exit();
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
- gpmc_dev = NULL;
+
return 0;
}
@@ -2282,25 +2321,6 @@ static __exit void gpmc_exit(void)
postcore_initcall(gpmc_init);
module_exit(gpmc_exit);
-static irqreturn_t gpmc_handle_irq(int irq, void *dev)
-{
- int i;
- u32 regval;
-
- regval = gpmc_read_reg(GPMC_IRQSTATUS);
-
- if (!regval)
- return IRQ_NONE;
-
- for (i = 0; i < GPMC_NR_IRQ; i++)
- if (regval & gpmc_client_irq[i].bitmask)
- generic_handle_irq(gpmc_client_irq[i].irq);
-
- gpmc_write_reg(GPMC_IRQSTATUS, regval);
-
- return IRQ_HANDLED;
-}
-
static struct omap3_gpmc_regs gpmc_context;
void omap3_gpmc_save_context(void)
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index dc2ada6..9e9d79e 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -11,8 +11,9 @@
#define GPMC_CONFIG_WP 0x00000005
-#define GPMC_IRQ_FIFOEVENTENABLE 0x01
-#define GPMC_IRQ_COUNT_EVENT 0x02
+/* IRQ numbers in GPMC IRQ domain for legacy boot use */
+#define GPMC_IRQ_FIFOEVENTENABLE 0
+#define GPMC_IRQ_COUNT_EVENT 1
/**
* gpmc_nand_ops - Interface between NAND and GPMC
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* Re: [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for NAND IRQs
@ 2016-04-11 14:52 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 14:52 UTC (permalink / raw)
To: Roger Quadros
Cc: tony, computersforpeace, boris.brezillon, dwmw2, ezequiel,
javier, fcooper, nsekhar, linux-mtd, linux-omap, devicetree,
linux-kernel
On Thu, Apr 07, 2016 at 01:08:23PM +0300, Roger Quadros wrote:
> GPMC provides 2 interrupts for NAND use. i.e. fifoevent and termcount.
> Use IRQ domain for this. NAND device tree node can then
> get the necessary interrupts by using gpmc as the interrupt parent.
>
> Legacy boot uses gpmc_get_client_irq to get the
> NAND interrupts from the GPMC IRQ domain.
> Get rid of custom bitmasks and use IRQ domain for that
> as well.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 8 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/memory/omap-gpmc.c | 246 ++++++++++++----------
> include/linux/omap-gpmc.h | 5 +-
> 3 files changed, 144 insertions(+), 115 deletions(-)
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for NAND IRQs
@ 2016-04-11 14:52 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 14:52 UTC (permalink / raw)
To: Roger Quadros
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
javier-0uQlZySMnqxg9hUCZPvPmw, fcooper-l0cyMroinI0,
nsekhar-l0cyMroinI0, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Thu, Apr 07, 2016 at 01:08:23PM +0300, Roger Quadros wrote:
> GPMC provides 2 interrupts for NAND use. i.e. fifoevent and termcount.
> Use IRQ domain for this. NAND device tree node can then
> get the necessary interrupts by using gpmc as the interrupt parent.
>
> Legacy boot uses gpmc_get_client_irq to get the
> NAND interrupts from the GPMC IRQ domain.
> Get rid of custom bitmasks and use IRQ domain for that
> as well.
>
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 8 +
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/memory/omap-gpmc.c | 246 ++++++++++++----------
> include/linux/omap-gpmc.h | 5 +-
> 3 files changed, 144 insertions(+), 115 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v6 06/17] mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Deprecate nand register passing via platform data and use
gpmc_omap_get_nand_ops() instead.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
arch/arm/mach-omap2/gpmc-nand.c | 2 --
drivers/mtd/nand/omap2.c | 9 ++++++++-
include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 72918c4..04e6998 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -121,8 +121,6 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
if (err < 0)
goto out_free_cs;
- gpmc_update_nand_reg(&gpmc_nand_data->reg, gpmc_nand_data->cs);
-
if (!gpmc_hwecc_bch_capable(gpmc_nand_data->ecc_opt)) {
pr_err("omap2-nand: Unsupported NAND ECC scheme selected\n");
err = -EINVAL;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0749ca1..cba9bf0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -28,6 +28,7 @@
#include <linux/mtd/nand_bch.h>
#include <linux/platform_data/elm.h>
+#include <linux/omap-gpmc.h>
#include <linux/platform_data/mtd-nand-omap2.h>
#define DRIVER_NAME "omap2-nand"
@@ -168,7 +169,9 @@ struct omap_nand_info {
} iomode;
u_char *buf;
int buf_len;
+ /* Interface to GPMC */
struct gpmc_nand_regs reg;
+ struct gpmc_nand_ops *ops;
/* generated at runtime depending on ECC algorithm and layout selected */
struct nand_ecclayout oobinfo;
/* fields specific for BCHx_HW ECC scheme */
@@ -1665,9 +1668,13 @@ static int omap_nand_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, info);
+ info->ops = gpmc_omap_get_nand_ops(&info->reg, info->gpmc_cs);
+ if (!info->ops) {
+ dev_err(&pdev->dev, "Failed to get GPMC->NAND interface\n");
+ return -ENODEV;
+ }
info->pdev = pdev;
info->gpmc_cs = pdata->cs;
- info->reg = pdata->reg;
info->of_node = pdata->of_node;
info->ecc_opt = pdata->ecc_opt;
nand_chip = &info->nand;
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index 090bbab..a067f58 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -75,10 +75,12 @@ struct omap_nand_platform_data {
enum nand_io xfer_type;
int devsize;
enum omap_ecc ecc_opt;
- struct gpmc_nand_regs reg;
/* for passing the partitions */
struct device_node *of_node;
struct device_node *elm_of_node;
+
+ /* deprecated */
+ struct gpmc_nand_regs reg;
};
#endif
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 06/17] mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: devicetree, nsekhar, linux-kernel, linux-mtd, ezequiel, javier,
linux-omap, dwmw2, fcooper, Roger Quadros
Deprecate nand register passing via platform data and use
gpmc_omap_get_nand_ops() instead.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
arch/arm/mach-omap2/gpmc-nand.c | 2 --
drivers/mtd/nand/omap2.c | 9 ++++++++-
include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 72918c4..04e6998 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -121,8 +121,6 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
if (err < 0)
goto out_free_cs;
- gpmc_update_nand_reg(&gpmc_nand_data->reg, gpmc_nand_data->cs);
-
if (!gpmc_hwecc_bch_capable(gpmc_nand_data->ecc_opt)) {
pr_err("omap2-nand: Unsupported NAND ECC scheme selected\n");
err = -EINVAL;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0749ca1..cba9bf0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -28,6 +28,7 @@
#include <linux/mtd/nand_bch.h>
#include <linux/platform_data/elm.h>
+#include <linux/omap-gpmc.h>
#include <linux/platform_data/mtd-nand-omap2.h>
#define DRIVER_NAME "omap2-nand"
@@ -168,7 +169,9 @@ struct omap_nand_info {
} iomode;
u_char *buf;
int buf_len;
+ /* Interface to GPMC */
struct gpmc_nand_regs reg;
+ struct gpmc_nand_ops *ops;
/* generated at runtime depending on ECC algorithm and layout selected */
struct nand_ecclayout oobinfo;
/* fields specific for BCHx_HW ECC scheme */
@@ -1665,9 +1668,13 @@ static int omap_nand_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, info);
+ info->ops = gpmc_omap_get_nand_ops(&info->reg, info->gpmc_cs);
+ if (!info->ops) {
+ dev_err(&pdev->dev, "Failed to get GPMC->NAND interface\n");
+ return -ENODEV;
+ }
info->pdev = pdev;
info->gpmc_cs = pdata->cs;
- info->reg = pdata->reg;
info->of_node = pdata->of_node;
info->ecc_opt = pdata->ecc_opt;
nand_chip = &info->nand;
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index 090bbab..a067f58 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -75,10 +75,12 @@ struct omap_nand_platform_data {
enum nand_io xfer_type;
int devsize;
enum omap_ecc ecc_opt;
- struct gpmc_nand_regs reg;
/* for passing the partitions */
struct device_node *of_node;
struct device_node *elm_of_node;
+
+ /* deprecated */
+ struct gpmc_nand_regs reg;
};
#endif
--
2.5.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 07/17] mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty check
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Instead of accessing the gpmc_status register directly start
using the gpmc_nand_ops->nand_writebuffer_empty() helper
to check write buffer empty status.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
drivers/mtd/nand/omap2.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index cba9bf0..98023d5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -291,14 +291,13 @@ static void omap_write_buf8(struct mtd_info *mtd, const u_char *buf, int len)
{
struct omap_nand_info *info = mtd_to_omap(mtd);
u_char *p = (u_char *)buf;
- u32 status = 0;
+ bool status;
while (len--) {
iowrite8(*p++, info->nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
- status = readl(info->reg.gpmc_status) &
- STATUS_BUFF_EMPTY;
+ status = info->ops->nand_writebuffer_empty();
} while (!status);
}
}
@@ -326,7 +325,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const u_char * buf, int len)
{
struct omap_nand_info *info = mtd_to_omap(mtd);
u16 *p = (u16 *) buf;
- u32 status = 0;
+ bool status;
/* FIXME try bursts of writesw() or DMA ... */
len >>= 1;
@@ -334,8 +333,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const u_char * buf, int len)
iowrite16(*p++, info->nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
- status = readl(info->reg.gpmc_status) &
- STATUS_BUFF_EMPTY;
+ status = info->ops->nand_writebuffer_empty();
} while (!status);
}
}
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 07/17] mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty check
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: devicetree, nsekhar, linux-kernel, linux-mtd, ezequiel, javier,
linux-omap, dwmw2, fcooper, Roger Quadros
Instead of accessing the gpmc_status register directly start
using the gpmc_nand_ops->nand_writebuffer_empty() helper
to check write buffer empty status.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
drivers/mtd/nand/omap2.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index cba9bf0..98023d5 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -291,14 +291,13 @@ static void omap_write_buf8(struct mtd_info *mtd, const u_char *buf, int len)
{
struct omap_nand_info *info = mtd_to_omap(mtd);
u_char *p = (u_char *)buf;
- u32 status = 0;
+ bool status;
while (len--) {
iowrite8(*p++, info->nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
- status = readl(info->reg.gpmc_status) &
- STATUS_BUFF_EMPTY;
+ status = info->ops->nand_writebuffer_empty();
} while (!status);
}
}
@@ -326,7 +325,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const u_char * buf, int len)
{
struct omap_nand_info *info = mtd_to_omap(mtd);
u16 *p = (u16 *) buf;
- u32 status = 0;
+ bool status;
/* FIXME try bursts of writesw() or DMA ... */
len >>= 1;
@@ -334,8 +333,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const u_char * buf, int len)
iowrite16(*p++, info->nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
- status = readl(info->reg.gpmc_status) &
- STATUS_BUFF_EMPTY;
+ status = info->ops->nand_writebuffer_empty();
} while (!status);
}
}
--
2.5.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 08/17] mtd: nand: omap: Copy platform data parameters to omap_nand_info data
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Copy all the platform data parameters to the driver's local data
structure 'omap_nand_info' and use it in the entire driver. This will
make it easer for device tree migration.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
drivers/mtd/nand/omap2.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 98023d5..7e4e263 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -152,13 +152,17 @@ static struct nand_hw_control omap_gpmc_controller = {
};
struct omap_nand_info {
- struct omap_nand_platform_data *pdata;
struct nand_chip nand;
struct platform_device *pdev;
int gpmc_cs;
- unsigned long phys_base;
+ bool dev_ready;
+ enum nand_io xfer_type;
+ int devsize;
enum omap_ecc ecc_opt;
+ struct device_node *elm_of_node;
+
+ unsigned long phys_base;
struct completion comp;
struct dma_chan *dma;
int gpmc_irq_fifo;
@@ -1631,7 +1635,7 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
"CONFIG_MTD_NAND_OMAP_BCH not enabled\n");
return false;
}
- if (ecc_needs_elm && !is_elm_present(info, pdata->elm_of_node)) {
+ if (ecc_needs_elm && !is_elm_present(info, info->elm_of_node)) {
dev_err(&info->pdev->dev, "ELM not available\n");
return false;
}
@@ -1675,6 +1679,11 @@ static int omap_nand_probe(struct platform_device *pdev)
info->gpmc_cs = pdata->cs;
info->of_node = pdata->of_node;
info->ecc_opt = pdata->ecc_opt;
+ info->dev_ready = pdata->dev_ready;
+ info->xfer_type = pdata->xfer_type;
+ info->devsize = pdata->devsize;
+ info->elm_of_node = pdata->elm_of_node;
+
nand_chip = &info->nand;
mtd = nand_to_mtd(nand_chip);
mtd->dev.parent = &pdev->dev;
@@ -1700,7 +1709,7 @@ static int omap_nand_probe(struct platform_device *pdev)
* chip delay which is slightly more than tR (AC Timing) of the NAND
* device and read status register until you get a failure or success
*/
- if (pdata->dev_ready) {
+ if (info->dev_ready) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
} else {
@@ -1714,15 +1723,16 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->options |= NAND_SKIP_BBTSCAN;
/* scan NAND device connected to chip controller */
- nand_chip->options |= pdata->devsize & NAND_BUSWIDTH_16;
+ nand_chip->options |= info->devsize & NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
- dev_err(&info->pdev->dev, "scan failed, may be bus-width mismatch\n");
+ dev_err(&info->pdev->dev,
+ "scan failed, may be bus-width mismatch\n");
err = -ENXIO;
goto return_error;
}
/* re-populate low-level callbacks based on xfer modes */
- switch (pdata->xfer_type) {
+ switch (info->xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
nand_chip->read_buf = omap_read_buf_pref;
nand_chip->write_buf = omap_write_buf_pref;
@@ -1802,7 +1812,7 @@ static int omap_nand_probe(struct platform_device *pdev)
default:
dev_err(&pdev->dev,
- "xfer_type(%d) not supported!\n", pdata->xfer_type);
+ "xfer_type(%d) not supported!\n", info->xfer_type);
err = -EINVAL;
goto return_error;
}
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 08/17] mtd: nand: omap: Copy platform data parameters to omap_nand_info data
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: devicetree, nsekhar, linux-kernel, linux-mtd, ezequiel, javier,
linux-omap, dwmw2, fcooper, Roger Quadros
Copy all the platform data parameters to the driver's local data
structure 'omap_nand_info' and use it in the entire driver. This will
make it easer for device tree migration.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
drivers/mtd/nand/omap2.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 98023d5..7e4e263 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -152,13 +152,17 @@ static struct nand_hw_control omap_gpmc_controller = {
};
struct omap_nand_info {
- struct omap_nand_platform_data *pdata;
struct nand_chip nand;
struct platform_device *pdev;
int gpmc_cs;
- unsigned long phys_base;
+ bool dev_ready;
+ enum nand_io xfer_type;
+ int devsize;
enum omap_ecc ecc_opt;
+ struct device_node *elm_of_node;
+
+ unsigned long phys_base;
struct completion comp;
struct dma_chan *dma;
int gpmc_irq_fifo;
@@ -1631,7 +1635,7 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
"CONFIG_MTD_NAND_OMAP_BCH not enabled\n");
return false;
}
- if (ecc_needs_elm && !is_elm_present(info, pdata->elm_of_node)) {
+ if (ecc_needs_elm && !is_elm_present(info, info->elm_of_node)) {
dev_err(&info->pdev->dev, "ELM not available\n");
return false;
}
@@ -1675,6 +1679,11 @@ static int omap_nand_probe(struct platform_device *pdev)
info->gpmc_cs = pdata->cs;
info->of_node = pdata->of_node;
info->ecc_opt = pdata->ecc_opt;
+ info->dev_ready = pdata->dev_ready;
+ info->xfer_type = pdata->xfer_type;
+ info->devsize = pdata->devsize;
+ info->elm_of_node = pdata->elm_of_node;
+
nand_chip = &info->nand;
mtd = nand_to_mtd(nand_chip);
mtd->dev.parent = &pdev->dev;
@@ -1700,7 +1709,7 @@ static int omap_nand_probe(struct platform_device *pdev)
* chip delay which is slightly more than tR (AC Timing) of the NAND
* device and read status register until you get a failure or success
*/
- if (pdata->dev_ready) {
+ if (info->dev_ready) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
} else {
@@ -1714,15 +1723,16 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->options |= NAND_SKIP_BBTSCAN;
/* scan NAND device connected to chip controller */
- nand_chip->options |= pdata->devsize & NAND_BUSWIDTH_16;
+ nand_chip->options |= info->devsize & NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
- dev_err(&info->pdev->dev, "scan failed, may be bus-width mismatch\n");
+ dev_err(&info->pdev->dev,
+ "scan failed, may be bus-width mismatch\n");
err = -ENXIO;
goto return_error;
}
/* re-populate low-level callbacks based on xfer modes */
- switch (pdata->xfer_type) {
+ switch (info->xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
nand_chip->read_buf = omap_read_buf_pref;
nand_chip->write_buf = omap_write_buf_pref;
@@ -1802,7 +1812,7 @@ static int omap_nand_probe(struct platform_device *pdev)
default:
dev_err(&pdev->dev,
- "xfer_type(%d) not supported!\n", pdata->xfer_type);
+ "xfer_type(%d) not supported!\n", info->xfer_type);
err = -EINVAL;
goto return_error;
}
--
2.5.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 09/17] mtd: nand: omap: Clean up device tree support
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Move NAND specific device tree parsing to NAND driver.
The NAND controller node must have a compatible id, register space
resource and interrupt resource.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
arch/arm/mach-omap2/gpmc-nand.c | 5 +-
drivers/memory/omap-gpmc.c | 143 +++++++--------------------
drivers/mtd/nand/omap2.c | 134 +++++++++++++++++++++----
include/linux/platform_data/mtd-nand-omap2.h | 3 +-
4 files changed, 153 insertions(+), 132 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 04e6998..f6ac027 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -97,10 +97,7 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
memset(&s, 0, sizeof(struct gpmc_settings));
- if (gpmc_nand_data->of_node)
- gpmc_read_settings_dt(gpmc_nand_data->of_node, &s);
- else
- gpmc_set_legacy(gpmc_nand_data, &s);
+ gpmc_set_legacy(gpmc_nand_data, &s);
s.device_nand = true;
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index e28d6bc..8dc6e3b 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -30,7 +30,6 @@
#include <linux/of_device.h>
#include <linux/of_platform.h>
#include <linux/omap-gpmc.h>
-#include <linux/mtd/nand.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mtd-nand-omap2.h>
@@ -1852,105 +1851,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_NAND)
-
-static const char * const nand_xfer_types[] = {
- [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
- [NAND_OMAP_POLLED] = "polled",
- [NAND_OMAP_PREFETCH_DMA] = "prefetch-dma",
- [NAND_OMAP_PREFETCH_IRQ] = "prefetch-irq",
-};
-
-static int gpmc_probe_nand_child(struct platform_device *pdev,
- struct device_node *child)
-{
- u32 val;
- const char *s;
- struct gpmc_timings gpmc_t;
- struct omap_nand_platform_data *gpmc_nand_data;
-
- if (of_property_read_u32(child, "reg", &val) < 0) {
- dev_err(&pdev->dev, "%s has no 'reg' property\n",
- child->full_name);
- return -ENODEV;
- }
-
- gpmc_nand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_nand_data),
- GFP_KERNEL);
- if (!gpmc_nand_data)
- return -ENOMEM;
-
- gpmc_nand_data->cs = val;
- gpmc_nand_data->of_node = child;
-
- /* Detect availability of ELM module */
- gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
- if (gpmc_nand_data->elm_of_node == NULL)
- gpmc_nand_data->elm_of_node =
- of_parse_phandle(child, "elm_id", 0);
-
- /* select ecc-scheme for NAND */
- if (of_property_read_string(child, "ti,nand-ecc-opt", &s)) {
- pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
- return -ENODEV;
- }
-
- if (!strcmp(s, "sw"))
- gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
- else if (!strcmp(s, "ham1") ||
- !strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_HAM1_CODE_HW;
- else if (!strcmp(s, "bch4"))
- if (gpmc_nand_data->elm_of_node)
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH4_CODE_HW;
- else
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
- else if (!strcmp(s, "bch8"))
- if (gpmc_nand_data->elm_of_node)
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH8_CODE_HW;
- else
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
- else if (!strcmp(s, "bch16"))
- if (gpmc_nand_data->elm_of_node)
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH16_CODE_HW;
- else
- pr_err("%s: BCH16 requires ELM support\n", __func__);
- else
- pr_err("%s: ti,nand-ecc-opt invalid value\n", __func__);
-
- /* select data transfer mode for NAND controller */
- if (!of_property_read_string(child, "ti,nand-xfer-type", &s))
- for (val = 0; val < ARRAY_SIZE(nand_xfer_types); val++)
- if (!strcasecmp(s, nand_xfer_types[val])) {
- gpmc_nand_data->xfer_type = val;
- break;
- }
-
- gpmc_nand_data->flash_bbt = of_get_nand_on_flash_bbt(child);
-
- val = of_get_nand_bus_width(child);
- if (val == 16)
- gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
-
- gpmc_read_timings_dt(child, &gpmc_t);
- gpmc_nand_init(gpmc_nand_data, &gpmc_t);
-
- return 0;
-}
-#else
-static int gpmc_probe_nand_child(struct platform_device *pdev,
- struct device_node *child)
-{
- return 0;
-}
-#endif
-
#if IS_ENABLED(CONFIG_MTD_ONENAND)
static int gpmc_probe_onenand_child(struct platform_device *pdev,
struct device_node *child)
@@ -2069,9 +1969,42 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
goto err;
}
- ret = of_property_read_u32(child, "bank-width", &gpmc_s.device_width);
- if (ret < 0)
- goto err;
+ if (of_node_cmp(child->name, "nand") == 0) {
+ /* Warn about older DT blobs with no compatible property */
+ if (!of_property_read_bool(child, "compatible")) {
+ dev_warn(&pdev->dev,
+ "Incompatible NAND node: missing compatible");
+ ret = -EINVAL;
+ goto err;
+ }
+ }
+
+ if (of_device_is_compatible(child, "ti,omap2-nand")) {
+ /* NAND specific setup */
+ val = of_get_nand_bus_width(child);
+ switch (val) {
+ case 8:
+ gpmc_s.device_width = GPMC_DEVWIDTH_8BIT;
+ break;
+ case 16:
+ gpmc_s.device_width = GPMC_DEVWIDTH_16BIT;
+ break;
+ default:
+ dev_err(&pdev->dev, "%s: invalid 'nand-bus-width'\n",
+ child->name);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ /* disable write protect */
+ gpmc_configure(GPMC_CONFIG_WP, 0);
+ gpmc_s.device_nand = true;
+ } else {
+ ret = of_property_read_u32(child, "bank-width",
+ &gpmc_s.device_width);
+ if (ret < 0)
+ goto err;
+ }
gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings");
ret = gpmc_cs_program_settings(cs, &gpmc_s);
@@ -2155,9 +2088,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
if (!child->name)
continue;
- if (of_node_cmp(child->name, "nand") == 0)
- ret = gpmc_probe_nand_child(pdev, child);
- else if (of_node_cmp(child->name, "onenand") == 0)
+ if (of_node_cmp(child->name, "onenand") == 0)
ret = gpmc_probe_onenand_child(pdev, child);
else
ret = gpmc_probe_generic_child(pdev, child);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7e4e263..35b8f33 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_mtd.h>
#include <linux/mtd/nand_bch.h>
#include <linux/platform_data/elm.h>
@@ -176,11 +177,11 @@ struct omap_nand_info {
/* Interface to GPMC */
struct gpmc_nand_regs reg;
struct gpmc_nand_ops *ops;
+ bool flash_bbt;
/* generated at runtime depending on ECC algorithm and layout selected */
struct nand_ecclayout oobinfo;
/* fields specific for BCHx_HW ECC scheme */
struct device *elm_dev;
- struct device_node *of_node;
};
static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd)
@@ -1643,10 +1644,86 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
return true;
}
+static const char * const nand_xfer_types[] = {
+ [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
+ [NAND_OMAP_POLLED] = "polled",
+ [NAND_OMAP_PREFETCH_DMA] = "prefetch-dma",
+ [NAND_OMAP_PREFETCH_IRQ] = "prefetch-irq",
+};
+
+static int omap_get_dt_info(struct device *dev, struct omap_nand_info *info)
+{
+ struct device_node *child = dev->of_node;
+ int i;
+ const char *s;
+ u32 cs;
+
+ if (of_property_read_u32(child, "reg", &cs) < 0) {
+ dev_err(dev, "reg not found in DT\n");
+ return -EINVAL;
+ }
+
+ info->gpmc_cs = cs;
+
+ /* detect availability of ELM module. Won't be present pre-OMAP4 */
+ info->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
+ if (!info->elm_of_node)
+ dev_dbg(dev, "ti,elm-id not in DT\n");
+
+ /* select ecc-scheme for NAND */
+ if (of_property_read_string(child, "ti,nand-ecc-opt", &s)) {
+ dev_err(dev, "ti,nand-ecc-opt not found\n");
+ return -EINVAL;
+ }
+
+ if (!strcmp(s, "sw")) {
+ info->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
+ } else if (!strcmp(s, "ham1") ||
+ !strcmp(s, "hw") || !strcmp(s, "hw-romcode")) {
+ info->ecc_opt = OMAP_ECC_HAM1_CODE_HW;
+ } else if (!strcmp(s, "bch4")) {
+ if (info->elm_of_node)
+ info->ecc_opt = OMAP_ECC_BCH4_CODE_HW;
+ else
+ info->ecc_opt = OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
+ } else if (!strcmp(s, "bch8")) {
+ if (info->elm_of_node)
+ info->ecc_opt = OMAP_ECC_BCH8_CODE_HW;
+ else
+ info->ecc_opt = OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
+ } else if (!strcmp(s, "bch16")) {
+ info->ecc_opt = OMAP_ECC_BCH16_CODE_HW;
+ } else {
+ dev_err(dev, "unrecognized value for ti,nand-ecc-opt\n");
+ return -EINVAL;
+ }
+
+ /* select data transfer mode */
+ if (!of_property_read_string(child, "ti,nand-xfer-type", &s)) {
+ for (i = 0; i < ARRAY_SIZE(nand_xfer_types); i++) {
+ if (!strcasecmp(s, nand_xfer_types[i])) {
+ info->xfer_type = i;
+ goto next;
+ }
+ }
+
+ dev_err(dev, "unrecognized value for ti,nand-xfer-type\n");
+ return -EINVAL;
+ }
+
+next:
+ of_get_nand_on_flash_bbt(child);
+
+ if (of_get_nand_bus_width(child) == 16)
+ info->devsize = NAND_BUSWIDTH_16;
+
+ return 0;
+}
+
static int omap_nand_probe(struct platform_device *pdev)
{
struct omap_nand_info *info;
- struct omap_nand_platform_data *pdata;
+ struct omap_nand_platform_data *pdata = NULL;
struct mtd_info *mtd;
struct nand_chip *nand_chip;
struct nand_ecclayout *ecclayout;
@@ -1656,39 +1733,47 @@ static int omap_nand_probe(struct platform_device *pdev)
unsigned sig;
unsigned oob_index;
struct resource *res;
-
- pdata = dev_get_platdata(&pdev->dev);
- if (pdata == NULL) {
- dev_err(&pdev->dev, "platform data missing\n");
- return -ENODEV;
- }
+ struct device *dev = &pdev->dev;
info = devm_kzalloc(&pdev->dev, sizeof(struct omap_nand_info),
GFP_KERNEL);
if (!info)
return -ENOMEM;
- platform_set_drvdata(pdev, info);
+ info->pdev = pdev;
+ if (dev->of_node) {
+ if (omap_get_dt_info(dev, info))
+ return -EINVAL;
+ } else {
+ pdata = dev_get_platdata(&pdev->dev);
+ if (!pdata) {
+ dev_err(&pdev->dev, "platform data missing\n");
+ return -EINVAL;
+ }
+
+ info->gpmc_cs = pdata->cs;
+ info->reg = pdata->reg;
+ info->ecc_opt = pdata->ecc_opt;
+ info->dev_ready = pdata->dev_ready;
+ info->xfer_type = pdata->xfer_type;
+ info->devsize = pdata->devsize;
+ info->elm_of_node = pdata->elm_of_node;
+ info->flash_bbt = pdata->flash_bbt;
+ }
+
+ platform_set_drvdata(pdev, info);
info->ops = gpmc_omap_get_nand_ops(&info->reg, info->gpmc_cs);
if (!info->ops) {
dev_err(&pdev->dev, "Failed to get GPMC->NAND interface\n");
return -ENODEV;
}
- info->pdev = pdev;
- info->gpmc_cs = pdata->cs;
- info->of_node = pdata->of_node;
- info->ecc_opt = pdata->ecc_opt;
- info->dev_ready = pdata->dev_ready;
- info->xfer_type = pdata->xfer_type;
- info->devsize = pdata->devsize;
- info->elm_of_node = pdata->elm_of_node;
nand_chip = &info->nand;
mtd = nand_to_mtd(nand_chip);
mtd->dev.parent = &pdev->dev;
nand_chip->ecc.priv = NULL;
- nand_set_flash_node(nand_chip, pdata->of_node);
+ nand_set_flash_node(nand_chip, dev->of_node);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
nand_chip->IO_ADDR_R = devm_ioremap_resource(&pdev->dev, res);
@@ -1717,7 +1802,7 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->chip_delay = 50;
}
- if (pdata->flash_bbt)
+ if (info->flash_bbt)
nand_chip->bbt_options |= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
else
nand_chip->options |= NAND_SKIP_BBTSCAN;
@@ -2035,7 +2120,10 @@ scan_tail:
goto return_error;
}
- mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
+ if (dev->of_node)
+ mtd_device_register(mtd, NULL, 0);
+ else
+ mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
platform_set_drvdata(pdev, mtd);
@@ -2066,11 +2154,17 @@ static int omap_nand_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id omap_nand_ids[] = {
+ { .compatible = "ti,omap2-nand", },
+ {},
+};
+
static struct platform_driver omap_nand_driver = {
.probe = omap_nand_probe,
.remove = omap_nand_remove,
.driver = {
.name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(omap_nand_ids),
},
};
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index a067f58..ff27e5a 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -76,11 +76,10 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
- /* for passing the partitions */
- struct device_node *of_node;
struct device_node *elm_of_node;
/* deprecated */
struct gpmc_nand_regs reg;
+ struct device_node *of_node;
};
#endif
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 09/17] mtd: nand: omap: Clean up device tree support
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Move NAND specific device tree parsing to NAND driver.
The NAND controller node must have a compatible id, register space
resource and interrupt resource.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
arch/arm/mach-omap2/gpmc-nand.c | 5 +-
drivers/memory/omap-gpmc.c | 143 +++++++--------------------
drivers/mtd/nand/omap2.c | 134 +++++++++++++++++++++----
include/linux/platform_data/mtd-nand-omap2.h | 3 +-
4 files changed, 153 insertions(+), 132 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 04e6998..f6ac027 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -97,10 +97,7 @@ int gpmc_nand_init(struct omap_nand_platform_data *gpmc_nand_data,
gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
memset(&s, 0, sizeof(struct gpmc_settings));
- if (gpmc_nand_data->of_node)
- gpmc_read_settings_dt(gpmc_nand_data->of_node, &s);
- else
- gpmc_set_legacy(gpmc_nand_data, &s);
+ gpmc_set_legacy(gpmc_nand_data, &s);
s.device_nand = true;
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index e28d6bc..8dc6e3b 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -30,7 +30,6 @@
#include <linux/of_device.h>
#include <linux/of_platform.h>
#include <linux/omap-gpmc.h>
-#include <linux/mtd/nand.h>
#include <linux/pm_runtime.h>
#include <linux/platform_data/mtd-nand-omap2.h>
@@ -1852,105 +1851,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_NAND)
-
-static const char * const nand_xfer_types[] = {
- [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
- [NAND_OMAP_POLLED] = "polled",
- [NAND_OMAP_PREFETCH_DMA] = "prefetch-dma",
- [NAND_OMAP_PREFETCH_IRQ] = "prefetch-irq",
-};
-
-static int gpmc_probe_nand_child(struct platform_device *pdev,
- struct device_node *child)
-{
- u32 val;
- const char *s;
- struct gpmc_timings gpmc_t;
- struct omap_nand_platform_data *gpmc_nand_data;
-
- if (of_property_read_u32(child, "reg", &val) < 0) {
- dev_err(&pdev->dev, "%s has no 'reg' property\n",
- child->full_name);
- return -ENODEV;
- }
-
- gpmc_nand_data = devm_kzalloc(&pdev->dev, sizeof(*gpmc_nand_data),
- GFP_KERNEL);
- if (!gpmc_nand_data)
- return -ENOMEM;
-
- gpmc_nand_data->cs = val;
- gpmc_nand_data->of_node = child;
-
- /* Detect availability of ELM module */
- gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
- if (gpmc_nand_data->elm_of_node == NULL)
- gpmc_nand_data->elm_of_node =
- of_parse_phandle(child, "elm_id", 0);
-
- /* select ecc-scheme for NAND */
- if (of_property_read_string(child, "ti,nand-ecc-opt", &s)) {
- pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
- return -ENODEV;
- }
-
- if (!strcmp(s, "sw"))
- gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
- else if (!strcmp(s, "ham1") ||
- !strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_HAM1_CODE_HW;
- else if (!strcmp(s, "bch4"))
- if (gpmc_nand_data->elm_of_node)
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH4_CODE_HW;
- else
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
- else if (!strcmp(s, "bch8"))
- if (gpmc_nand_data->elm_of_node)
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH8_CODE_HW;
- else
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
- else if (!strcmp(s, "bch16"))
- if (gpmc_nand_data->elm_of_node)
- gpmc_nand_data->ecc_opt =
- OMAP_ECC_BCH16_CODE_HW;
- else
- pr_err("%s: BCH16 requires ELM support\n", __func__);
- else
- pr_err("%s: ti,nand-ecc-opt invalid value\n", __func__);
-
- /* select data transfer mode for NAND controller */
- if (!of_property_read_string(child, "ti,nand-xfer-type", &s))
- for (val = 0; val < ARRAY_SIZE(nand_xfer_types); val++)
- if (!strcasecmp(s, nand_xfer_types[val])) {
- gpmc_nand_data->xfer_type = val;
- break;
- }
-
- gpmc_nand_data->flash_bbt = of_get_nand_on_flash_bbt(child);
-
- val = of_get_nand_bus_width(child);
- if (val == 16)
- gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
-
- gpmc_read_timings_dt(child, &gpmc_t);
- gpmc_nand_init(gpmc_nand_data, &gpmc_t);
-
- return 0;
-}
-#else
-static int gpmc_probe_nand_child(struct platform_device *pdev,
- struct device_node *child)
-{
- return 0;
-}
-#endif
-
#if IS_ENABLED(CONFIG_MTD_ONENAND)
static int gpmc_probe_onenand_child(struct platform_device *pdev,
struct device_node *child)
@@ -2069,9 +1969,42 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
goto err;
}
- ret = of_property_read_u32(child, "bank-width", &gpmc_s.device_width);
- if (ret < 0)
- goto err;
+ if (of_node_cmp(child->name, "nand") == 0) {
+ /* Warn about older DT blobs with no compatible property */
+ if (!of_property_read_bool(child, "compatible")) {
+ dev_warn(&pdev->dev,
+ "Incompatible NAND node: missing compatible");
+ ret = -EINVAL;
+ goto err;
+ }
+ }
+
+ if (of_device_is_compatible(child, "ti,omap2-nand")) {
+ /* NAND specific setup */
+ val = of_get_nand_bus_width(child);
+ switch (val) {
+ case 8:
+ gpmc_s.device_width = GPMC_DEVWIDTH_8BIT;
+ break;
+ case 16:
+ gpmc_s.device_width = GPMC_DEVWIDTH_16BIT;
+ break;
+ default:
+ dev_err(&pdev->dev, "%s: invalid 'nand-bus-width'\n",
+ child->name);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ /* disable write protect */
+ gpmc_configure(GPMC_CONFIG_WP, 0);
+ gpmc_s.device_nand = true;
+ } else {
+ ret = of_property_read_u32(child, "bank-width",
+ &gpmc_s.device_width);
+ if (ret < 0)
+ goto err;
+ }
gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings");
ret = gpmc_cs_program_settings(cs, &gpmc_s);
@@ -2155,9 +2088,7 @@ static int gpmc_probe_dt(struct platform_device *pdev)
if (!child->name)
continue;
- if (of_node_cmp(child->name, "nand") == 0)
- ret = gpmc_probe_nand_child(pdev, child);
- else if (of_node_cmp(child->name, "onenand") == 0)
+ if (of_node_cmp(child->name, "onenand") == 0)
ret = gpmc_probe_onenand_child(pdev, child);
else
ret = gpmc_probe_generic_child(pdev, child);
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 7e4e263..35b8f33 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_mtd.h>
#include <linux/mtd/nand_bch.h>
#include <linux/platform_data/elm.h>
@@ -176,11 +177,11 @@ struct omap_nand_info {
/* Interface to GPMC */
struct gpmc_nand_regs reg;
struct gpmc_nand_ops *ops;
+ bool flash_bbt;
/* generated at runtime depending on ECC algorithm and layout selected */
struct nand_ecclayout oobinfo;
/* fields specific for BCHx_HW ECC scheme */
struct device *elm_dev;
- struct device_node *of_node;
};
static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd)
@@ -1643,10 +1644,86 @@ static bool omap2_nand_ecc_check(struct omap_nand_info *info,
return true;
}
+static const char * const nand_xfer_types[] = {
+ [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
+ [NAND_OMAP_POLLED] = "polled",
+ [NAND_OMAP_PREFETCH_DMA] = "prefetch-dma",
+ [NAND_OMAP_PREFETCH_IRQ] = "prefetch-irq",
+};
+
+static int omap_get_dt_info(struct device *dev, struct omap_nand_info *info)
+{
+ struct device_node *child = dev->of_node;
+ int i;
+ const char *s;
+ u32 cs;
+
+ if (of_property_read_u32(child, "reg", &cs) < 0) {
+ dev_err(dev, "reg not found in DT\n");
+ return -EINVAL;
+ }
+
+ info->gpmc_cs = cs;
+
+ /* detect availability of ELM module. Won't be present pre-OMAP4 */
+ info->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
+ if (!info->elm_of_node)
+ dev_dbg(dev, "ti,elm-id not in DT\n");
+
+ /* select ecc-scheme for NAND */
+ if (of_property_read_string(child, "ti,nand-ecc-opt", &s)) {
+ dev_err(dev, "ti,nand-ecc-opt not found\n");
+ return -EINVAL;
+ }
+
+ if (!strcmp(s, "sw")) {
+ info->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
+ } else if (!strcmp(s, "ham1") ||
+ !strcmp(s, "hw") || !strcmp(s, "hw-romcode")) {
+ info->ecc_opt = OMAP_ECC_HAM1_CODE_HW;
+ } else if (!strcmp(s, "bch4")) {
+ if (info->elm_of_node)
+ info->ecc_opt = OMAP_ECC_BCH4_CODE_HW;
+ else
+ info->ecc_opt = OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
+ } else if (!strcmp(s, "bch8")) {
+ if (info->elm_of_node)
+ info->ecc_opt = OMAP_ECC_BCH8_CODE_HW;
+ else
+ info->ecc_opt = OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
+ } else if (!strcmp(s, "bch16")) {
+ info->ecc_opt = OMAP_ECC_BCH16_CODE_HW;
+ } else {
+ dev_err(dev, "unrecognized value for ti,nand-ecc-opt\n");
+ return -EINVAL;
+ }
+
+ /* select data transfer mode */
+ if (!of_property_read_string(child, "ti,nand-xfer-type", &s)) {
+ for (i = 0; i < ARRAY_SIZE(nand_xfer_types); i++) {
+ if (!strcasecmp(s, nand_xfer_types[i])) {
+ info->xfer_type = i;
+ goto next;
+ }
+ }
+
+ dev_err(dev, "unrecognized value for ti,nand-xfer-type\n");
+ return -EINVAL;
+ }
+
+next:
+ of_get_nand_on_flash_bbt(child);
+
+ if (of_get_nand_bus_width(child) == 16)
+ info->devsize = NAND_BUSWIDTH_16;
+
+ return 0;
+}
+
static int omap_nand_probe(struct platform_device *pdev)
{
struct omap_nand_info *info;
- struct omap_nand_platform_data *pdata;
+ struct omap_nand_platform_data *pdata = NULL;
struct mtd_info *mtd;
struct nand_chip *nand_chip;
struct nand_ecclayout *ecclayout;
@@ -1656,39 +1733,47 @@ static int omap_nand_probe(struct platform_device *pdev)
unsigned sig;
unsigned oob_index;
struct resource *res;
-
- pdata = dev_get_platdata(&pdev->dev);
- if (pdata == NULL) {
- dev_err(&pdev->dev, "platform data missing\n");
- return -ENODEV;
- }
+ struct device *dev = &pdev->dev;
info = devm_kzalloc(&pdev->dev, sizeof(struct omap_nand_info),
GFP_KERNEL);
if (!info)
return -ENOMEM;
- platform_set_drvdata(pdev, info);
+ info->pdev = pdev;
+ if (dev->of_node) {
+ if (omap_get_dt_info(dev, info))
+ return -EINVAL;
+ } else {
+ pdata = dev_get_platdata(&pdev->dev);
+ if (!pdata) {
+ dev_err(&pdev->dev, "platform data missing\n");
+ return -EINVAL;
+ }
+
+ info->gpmc_cs = pdata->cs;
+ info->reg = pdata->reg;
+ info->ecc_opt = pdata->ecc_opt;
+ info->dev_ready = pdata->dev_ready;
+ info->xfer_type = pdata->xfer_type;
+ info->devsize = pdata->devsize;
+ info->elm_of_node = pdata->elm_of_node;
+ info->flash_bbt = pdata->flash_bbt;
+ }
+
+ platform_set_drvdata(pdev, info);
info->ops = gpmc_omap_get_nand_ops(&info->reg, info->gpmc_cs);
if (!info->ops) {
dev_err(&pdev->dev, "Failed to get GPMC->NAND interface\n");
return -ENODEV;
}
- info->pdev = pdev;
- info->gpmc_cs = pdata->cs;
- info->of_node = pdata->of_node;
- info->ecc_opt = pdata->ecc_opt;
- info->dev_ready = pdata->dev_ready;
- info->xfer_type = pdata->xfer_type;
- info->devsize = pdata->devsize;
- info->elm_of_node = pdata->elm_of_node;
nand_chip = &info->nand;
mtd = nand_to_mtd(nand_chip);
mtd->dev.parent = &pdev->dev;
nand_chip->ecc.priv = NULL;
- nand_set_flash_node(nand_chip, pdata->of_node);
+ nand_set_flash_node(nand_chip, dev->of_node);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
nand_chip->IO_ADDR_R = devm_ioremap_resource(&pdev->dev, res);
@@ -1717,7 +1802,7 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->chip_delay = 50;
}
- if (pdata->flash_bbt)
+ if (info->flash_bbt)
nand_chip->bbt_options |= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
else
nand_chip->options |= NAND_SKIP_BBTSCAN;
@@ -2035,7 +2120,10 @@ scan_tail:
goto return_error;
}
- mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
+ if (dev->of_node)
+ mtd_device_register(mtd, NULL, 0);
+ else
+ mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
platform_set_drvdata(pdev, mtd);
@@ -2066,11 +2154,17 @@ static int omap_nand_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id omap_nand_ids[] = {
+ { .compatible = "ti,omap2-nand", },
+ {},
+};
+
static struct platform_driver omap_nand_driver = {
.probe = omap_nand_probe,
.remove = omap_nand_remove,
.driver = {
.name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(omap_nand_ids),
},
};
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index a067f58..ff27e5a 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -76,11 +76,10 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
- /* for passing the partitions */
- struct device_node *of_node;
struct device_node *elm_of_node;
/* deprecated */
struct gpmc_nand_regs reg;
+ struct device_node *of_node;
};
#endif
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 10/17] mtd: nand: omap: Update DT binding documentation
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Add compatible id and interrupts. The NAND interrupts are
provided by the GPMC controller node.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index fb733c4..ff3215d2 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -13,7 +13,11 @@ Documentation/devicetree/bindings/mtd/nand.txt
Required properties:
- - reg: The CS line the peripheral is connected to
+ - compatible: "ti,omap2-nand"
+ - reg: range id (CS number), base offset and length of the
+ NAND I/O space
+ - interrupt-parent: must point to gpmc node
+ - interrupts: Two interrupt specifiers, one for fifoevent, one for termcount.
Optional properties:
@@ -55,17 +59,22 @@ Example for an AM33xx board:
gpmc: gpmc@50000000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
- reg = <0x50000000 0x1000000>;
+ reg = <0x50000000 0x36c>;
interrupts = <100>;
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
#size-cells = <1>;
- ranges = <0 0 0x08000000 0x2000>; /* CS0: NAND */
+ ranges = <0 0 0x08000000 0x1000000>; /* CS0 space, 16MB */
elm_id = <&elm>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
nand@0,0 {
- reg = <0 0 0>; /* CS0, offset 0 */
+ compatible = "ti,omap2-nand";
+ reg = <0 0 4>; /* CS0, offset 0, NAND I/O window 4 */
+ interrupt-parent = <&gpmc>;
+ interrupts = <0 IRQ_TYPE_NONE>, <1 IRQ_TYPE NONE>;
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
ti,nand-xfer-type = "polled";
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 10/17] mtd: nand: omap: Update DT binding documentation
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
Add compatible id and interrupts. The NAND interrupts are
provided by the GPMC controller node.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Brian Norris <computersforpeace@gmail.com>
---
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index fb733c4..ff3215d2 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -13,7 +13,11 @@ Documentation/devicetree/bindings/mtd/nand.txt
Required properties:
- - reg: The CS line the peripheral is connected to
+ - compatible: "ti,omap2-nand"
+ - reg: range id (CS number), base offset and length of the
+ NAND I/O space
+ - interrupt-parent: must point to gpmc node
+ - interrupts: Two interrupt specifiers, one for fifoevent, one for termcount.
Optional properties:
@@ -55,17 +59,22 @@ Example for an AM33xx board:
gpmc: gpmc@50000000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
- reg = <0x50000000 0x1000000>;
+ reg = <0x50000000 0x36c>;
interrupts = <100>;
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
#size-cells = <1>;
- ranges = <0 0 0x08000000 0x2000>; /* CS0: NAND */
+ ranges = <0 0 0x08000000 0x1000000>; /* CS0 space, 16MB */
elm_id = <&elm>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
nand@0,0 {
- reg = <0 0 0>; /* CS0, offset 0 */
+ compatible = "ti,omap2-nand";
+ reg = <0 0 4>; /* CS0, offset 0, NAND I/O window 4 */
+ interrupt-parent = <&gpmc>;
+ interrupts = <0 IRQ_TYPE_NONE>, <1 IRQ_TYPE NONE>;
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
ti,nand-xfer-type = "polled";
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 11/17] memory: omap-gpmc: Prevent mapping into 1st 16MB
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
We have been preventing mapping GPMC children in the
first 1MB but really it has to be the first 16MB as
the minimum GPMC partition size is 16MB.
Also print an error message if CS mapping fails
due to DT requesting address outside the GPMC
map.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 8dc6e3b..bfe4e87 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -94,6 +94,14 @@
#define GPMC_CS_SIZE 0x30
#define GPMC_BCH_SIZE 0x10
+/*
+ * The first 1MB of GPMC address space is typically mapped to
+ * the internal ROM. Never allocate the first page, to
+ * facilitate bug detection; even if we didn't boot from ROM.
+ * As GPMC minimum partition size is 16MB we can only start from
+ * there.
+ */
+#define GPMC_MEM_START 0x1000000
#define GPMC_MEM_END 0x3FFFFFFF
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
@@ -1297,12 +1305,7 @@ static void gpmc_mem_init(void)
{
int cs;
- /*
- * The first 1MB of GPMC address space is typically mapped to
- * the internal ROM. Never allocate the first page, to
- * facilitate bug detection; even if we didn't boot from ROM.
- */
- gpmc_mem_root.start = SZ_1M;
+ gpmc_mem_root.start = GPMC_MEM_START;
gpmc_mem_root.end = GPMC_MEM_END;
/* Reserve all regions that has been set up by bootloader */
@@ -1966,6 +1969,15 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
if (ret < 0) {
dev_err(&pdev->dev, "cannot remap GPMC CS %d to %pa\n",
cs, &res.start);
+ if (res.start < GPMC_MEM_START) {
+ dev_info(&pdev->dev,
+ "GPMC CS %d start cannot be lesser than 0x%x\n",
+ cs, GPMC_MEM_START);
+ } else if (res.end > GPMC_MEM_END) {
+ dev_info(&pdev->dev,
+ "GPMC CS %d end cannot be greater than 0x%x\n",
+ cs, GPMC_MEM_END);
+ }
goto err;
}
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 11/17] memory: omap-gpmc: Prevent mapping into 1st 16MB
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: devicetree, nsekhar, linux-kernel, linux-mtd, ezequiel, javier,
linux-omap, dwmw2, fcooper, Roger Quadros
We have been preventing mapping GPMC children in the
first 1MB but really it has to be the first 16MB as
the minimum GPMC partition size is 16MB.
Also print an error message if CS mapping fails
due to DT requesting address outside the GPMC
map.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 8dc6e3b..bfe4e87 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -94,6 +94,14 @@
#define GPMC_CS_SIZE 0x30
#define GPMC_BCH_SIZE 0x10
+/*
+ * The first 1MB of GPMC address space is typically mapped to
+ * the internal ROM. Never allocate the first page, to
+ * facilitate bug detection; even if we didn't boot from ROM.
+ * As GPMC minimum partition size is 16MB we can only start from
+ * there.
+ */
+#define GPMC_MEM_START 0x1000000
#define GPMC_MEM_END 0x3FFFFFFF
#define GPMC_CHUNK_SHIFT 24 /* 16 MB */
@@ -1297,12 +1305,7 @@ static void gpmc_mem_init(void)
{
int cs;
- /*
- * The first 1MB of GPMC address space is typically mapped to
- * the internal ROM. Never allocate the first page, to
- * facilitate bug detection; even if we didn't boot from ROM.
- */
- gpmc_mem_root.start = SZ_1M;
+ gpmc_mem_root.start = GPMC_MEM_START;
gpmc_mem_root.end = GPMC_MEM_END;
/* Reserve all regions that has been set up by bootloader */
@@ -1966,6 +1969,15 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
if (ret < 0) {
dev_err(&pdev->dev, "cannot remap GPMC CS %d to %pa\n",
cs, &res.start);
+ if (res.start < GPMC_MEM_START) {
+ dev_info(&pdev->dev,
+ "GPMC CS %d start cannot be lesser than 0x%x\n",
+ cs, GPMC_MEM_START);
+ } else if (res.end > GPMC_MEM_END) {
+ dev_info(&pdev->dev,
+ "GPMC CS %d end cannot be greater than 0x%x\n",
+ cs, GPMC_MEM_END);
+ }
goto err;
}
--
2.5.0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 12/17] memory: omap-gpmc: Move device tree binding to correct location
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
omap-gpmc.c is a memory controller so move the binding to the
right place.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} (100%)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/bus/ti-gpmc.txt
rename to Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
--
2.5.0
^ permalink raw reply [flat|nested] 93+ messages in thread* [PATCH v6 12/17] memory: omap-gpmc: Move device tree binding to correct location
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
omap-gpmc.c is a memory controller so move the binding to the
right place.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} (100%)
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/bus/ti-gpmc.txt
rename to Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
--
2.5.0
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v6 13/17] memory: omap-gpmc: Support general purpose input for WAITPINs
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
OMAPs can have 2 to 4 WAITPINs that can be used as general purpose
input if not used for memory wait state insertion.
The first user will be the OMAP NAND chip to get the NAND
read/busy status using gpiolib.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../bindings/memory-controllers/omap-gpmc.txt | 6 ++
drivers/memory/Kconfig | 1 +
drivers/memory/omap-gpmc.c | 117 ++++++++++++++++++---
3 files changed, 112 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 13f1378..97e7192 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -38,6 +38,10 @@ Required properties:
0 - NAND_fifoevent
1 - NAND_termcount
- interrupt-cells: Must be set to 2
+ - gpio-controller: The GPMC driver implements a GPIO controller for the
+ GPMC WAIT pins that can be used as general purpose inputs.
+ 0 maps to GPMC_WAIT0 pin.
+ - gpio-cells: Must be set to 2
Timing properties for child nodes. All are optional and default to 0.
@@ -138,6 +142,8 @@ Example for an AM33xx board:
ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
/* child nodes go here */
};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 51d5cd2..a9b1c14 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -51,6 +51,7 @@ config TI_EMIF
config OMAP_GPMC
bool
+ select GPIOLIB
help
This driver is for the General Purpose Memory Controller (GPMC)
present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index bfe4e87..4dd1c65 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -21,6 +21,7 @@
#include <linux/spinlock.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/gpio/driver.h>
#include <linux/interrupt.h>
#include <linux/irqdomain.h>
#include <linux/platform_device.h>
@@ -237,6 +238,7 @@ struct gpmc_device {
struct device *dev;
int irq;
struct irq_chip irq_chip;
+ struct gpio_chip gpio_chip;
};
static struct irq_domain *gpmc_irq_domain;
@@ -2064,10 +2066,71 @@ err:
return ret;
}
+static int gpmc_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ return 1; /* we're input only */
+}
+
+static int gpmc_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ return 0; /* we're input only */
+}
+
+static int gpmc_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ return -EINVAL; /* we're input only */
+}
+
+static void gpmc_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+}
+
+static int gpmc_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ u32 reg;
+
+ offset += 8;
+
+ reg = gpmc_read_reg(GPMC_STATUS) & BIT(offset);
+
+ return !!reg;
+}
+
+static int gpmc_gpio_init(struct gpmc_device *gpmc)
+{
+ int ret;
+
+ gpmc->gpio_chip.parent = gpmc->dev;
+ gpmc->gpio_chip.owner = THIS_MODULE;
+ gpmc->gpio_chip.label = DEVICE_NAME;
+ gpmc->gpio_chip.ngpio = gpmc_nr_waitpins;
+ gpmc->gpio_chip.get_direction = gpmc_gpio_get_direction;
+ gpmc->gpio_chip.direction_input = gpmc_gpio_direction_input;
+ gpmc->gpio_chip.direction_output = gpmc_gpio_direction_output;
+ gpmc->gpio_chip.set = gpmc_gpio_set;
+ gpmc->gpio_chip.get = gpmc_gpio_get;
+ gpmc->gpio_chip.base = -1;
+
+ ret = gpiochip_add(&gpmc->gpio_chip);
+ if (ret < 0) {
+ dev_err(gpmc->dev, "could not register gpio chip: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void gpmc_gpio_exit(struct gpmc_device *gpmc)
+{
+ gpiochip_remove(&gpmc->gpio_chip);
+}
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
- struct device_node *child;
const struct of_device_id *of_id =
of_match_device(gpmc_dt_ids, &pdev->dev);
@@ -2095,6 +2158,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ return 0;
+}
+
+static int gpmc_probe_dt_children(struct platform_device *pdev)
+{
+ int ret;
+ struct device_node *child;
+
for_each_available_child_of_node(pdev->dev.of_node, child) {
if (!child->name)
@@ -2104,6 +2175,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
ret = gpmc_probe_onenand_child(pdev, child);
else
ret = gpmc_probe_generic_child(pdev, child);
+
+ if (ret)
+ return ret;
}
return 0;
@@ -2113,6 +2187,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
{
return 0;
}
+
+static int gpmc_probe_dt_children(struct platform_device *pdev)
+{
+ return 0;
+}
#endif
static int gpmc_probe(struct platform_device *pdev)
@@ -2159,6 +2238,15 @@ static int gpmc_probe(struct platform_device *pdev)
return -EINVAL;
}
+ if (pdev->dev.of_node) {
+ rc = gpmc_probe_dt(pdev);
+ if (rc)
+ return rc;
+ } else {
+ gpmc_cs_num = GPMC_CS_NUM;
+ gpmc_nr_waitpins = GPMC_NR_WAITPINS;
+ }
+
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
@@ -2184,29 +2272,33 @@ static int gpmc_probe(struct platform_device *pdev)
GPMC_REVISION_MINOR(l));
gpmc_mem_init();
+ rc = gpmc_gpio_init(gpmc);
+ if (rc)
+ goto gpio_init_failed;
rc = gpmc_setup_irq(gpmc);
if (rc) {
dev_err(gpmc->dev, "gpmc_setup_irq failed\n");
- goto fail;
+ goto setup_irq_failed;
}
- if (!pdev->dev.of_node) {
- gpmc_cs_num = GPMC_CS_NUM;
- gpmc_nr_waitpins = GPMC_NR_WAITPINS;
- }
-
- rc = gpmc_probe_dt(pdev);
+ rc = gpmc_probe_dt_children(pdev);
if (rc < 0) {
- dev_err(gpmc->dev, "failed to probe DT parameters\n");
- gpmc_free_irq(gpmc);
- goto fail;
+ dev_err(gpmc->dev, "failed to probe DT children\n");
+ goto dt_children_failed;
}
return 0;
-fail:
+dt_children_failed:
+ gpmc_free_irq(gpmc);
+setup_irq_failed:
+ gpmc_gpio_exit(gpmc);
+gpio_init_failed:
+ gpmc_mem_exit();
pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
return rc;
}
@@ -2215,6 +2307,7 @@ static int gpmc_remove(struct platform_device *pdev)
struct gpmc_device *gpmc = platform_get_drvdata(pdev);
gpmc_free_irq(gpmc);
+ gpmc_gpio_exit(gpmc);
gpmc_mem_exit();
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 13/17] memory: omap-gpmc: Support general purpose input for WAITPINs
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
OMAPs can have 2 to 4 WAITPINs that can be used as general purpose
input if not used for memory wait state insertion.
The first user will be the OMAP NAND chip to get the NAND
read/busy status using gpiolib.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../bindings/memory-controllers/omap-gpmc.txt | 6 ++
drivers/memory/Kconfig | 1 +
drivers/memory/omap-gpmc.c | 117 ++++++++++++++++++---
3 files changed, 112 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 13f1378..97e7192 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -38,6 +38,10 @@ Required properties:
0 - NAND_fifoevent
1 - NAND_termcount
- interrupt-cells: Must be set to 2
+ - gpio-controller: The GPMC driver implements a GPIO controller for the
+ GPMC WAIT pins that can be used as general purpose inputs.
+ 0 maps to GPMC_WAIT0 pin.
+ - gpio-cells: Must be set to 2
Timing properties for child nodes. All are optional and default to 0.
@@ -138,6 +142,8 @@ Example for an AM33xx board:
ranges = <0 0 0x08000000 0x10000000>; /* CS0 @addr 0x8000000, size 0x10000000 */
interrupt-controller;
#interrupt-cells = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
/* child nodes go here */
};
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 51d5cd2..a9b1c14 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -51,6 +51,7 @@ config TI_EMIF
config OMAP_GPMC
bool
+ select GPIOLIB
help
This driver is for the General Purpose Memory Controller (GPMC)
present on Texas Instruments SoCs (e.g. OMAP2+). GPMC allows
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index bfe4e87..4dd1c65 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -21,6 +21,7 @@
#include <linux/spinlock.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/gpio/driver.h>
#include <linux/interrupt.h>
#include <linux/irqdomain.h>
#include <linux/platform_device.h>
@@ -237,6 +238,7 @@ struct gpmc_device {
struct device *dev;
int irq;
struct irq_chip irq_chip;
+ struct gpio_chip gpio_chip;
};
static struct irq_domain *gpmc_irq_domain;
@@ -2064,10 +2066,71 @@ err:
return ret;
}
+static int gpmc_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ return 1; /* we're input only */
+}
+
+static int gpmc_gpio_direction_input(struct gpio_chip *chip,
+ unsigned int offset)
+{
+ return 0; /* we're input only */
+}
+
+static int gpmc_gpio_direction_output(struct gpio_chip *chip,
+ unsigned int offset, int value)
+{
+ return -EINVAL; /* we're input only */
+}
+
+static void gpmc_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int value)
+{
+}
+
+static int gpmc_gpio_get(struct gpio_chip *chip, unsigned int offset)
+{
+ u32 reg;
+
+ offset += 8;
+
+ reg = gpmc_read_reg(GPMC_STATUS) & BIT(offset);
+
+ return !!reg;
+}
+
+static int gpmc_gpio_init(struct gpmc_device *gpmc)
+{
+ int ret;
+
+ gpmc->gpio_chip.parent = gpmc->dev;
+ gpmc->gpio_chip.owner = THIS_MODULE;
+ gpmc->gpio_chip.label = DEVICE_NAME;
+ gpmc->gpio_chip.ngpio = gpmc_nr_waitpins;
+ gpmc->gpio_chip.get_direction = gpmc_gpio_get_direction;
+ gpmc->gpio_chip.direction_input = gpmc_gpio_direction_input;
+ gpmc->gpio_chip.direction_output = gpmc_gpio_direction_output;
+ gpmc->gpio_chip.set = gpmc_gpio_set;
+ gpmc->gpio_chip.get = gpmc_gpio_get;
+ gpmc->gpio_chip.base = -1;
+
+ ret = gpiochip_add(&gpmc->gpio_chip);
+ if (ret < 0) {
+ dev_err(gpmc->dev, "could not register gpio chip: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void gpmc_gpio_exit(struct gpmc_device *gpmc)
+{
+ gpiochip_remove(&gpmc->gpio_chip);
+}
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
- struct device_node *child;
const struct of_device_id *of_id =
of_match_device(gpmc_dt_ids, &pdev->dev);
@@ -2095,6 +2158,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
+ return 0;
+}
+
+static int gpmc_probe_dt_children(struct platform_device *pdev)
+{
+ int ret;
+ struct device_node *child;
+
for_each_available_child_of_node(pdev->dev.of_node, child) {
if (!child->name)
@@ -2104,6 +2175,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
ret = gpmc_probe_onenand_child(pdev, child);
else
ret = gpmc_probe_generic_child(pdev, child);
+
+ if (ret)
+ return ret;
}
return 0;
@@ -2113,6 +2187,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
{
return 0;
}
+
+static int gpmc_probe_dt_children(struct platform_device *pdev)
+{
+ return 0;
+}
#endif
static int gpmc_probe(struct platform_device *pdev)
@@ -2159,6 +2238,15 @@ static int gpmc_probe(struct platform_device *pdev)
return -EINVAL;
}
+ if (pdev->dev.of_node) {
+ rc = gpmc_probe_dt(pdev);
+ if (rc)
+ return rc;
+ } else {
+ gpmc_cs_num = GPMC_CS_NUM;
+ gpmc_nr_waitpins = GPMC_NR_WAITPINS;
+ }
+
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
@@ -2184,29 +2272,33 @@ static int gpmc_probe(struct platform_device *pdev)
GPMC_REVISION_MINOR(l));
gpmc_mem_init();
+ rc = gpmc_gpio_init(gpmc);
+ if (rc)
+ goto gpio_init_failed;
rc = gpmc_setup_irq(gpmc);
if (rc) {
dev_err(gpmc->dev, "gpmc_setup_irq failed\n");
- goto fail;
+ goto setup_irq_failed;
}
- if (!pdev->dev.of_node) {
- gpmc_cs_num = GPMC_CS_NUM;
- gpmc_nr_waitpins = GPMC_NR_WAITPINS;
- }
-
- rc = gpmc_probe_dt(pdev);
+ rc = gpmc_probe_dt_children(pdev);
if (rc < 0) {
- dev_err(gpmc->dev, "failed to probe DT parameters\n");
- gpmc_free_irq(gpmc);
- goto fail;
+ dev_err(gpmc->dev, "failed to probe DT children\n");
+ goto dt_children_failed;
}
return 0;
-fail:
+dt_children_failed:
+ gpmc_free_irq(gpmc);
+setup_irq_failed:
+ gpmc_gpio_exit(gpmc);
+gpio_init_failed:
+ gpmc_mem_exit();
pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
return rc;
}
@@ -2215,6 +2307,7 @@ static int gpmc_remove(struct platform_device *pdev)
struct gpmc_device *gpmc = platform_get_drvdata(pdev);
gpmc_free_irq(gpmc);
+ gpmc_gpio_exit(gpmc);
gpmc_mem_exit();
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* Re: [PATCH v6 13/17] memory: omap-gpmc: Support general purpose input for WAITPINs
@ 2016-04-11 15:00 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 15:00 UTC (permalink / raw)
To: Roger Quadros
Cc: tony, computersforpeace, boris.brezillon, dwmw2, ezequiel,
javier, fcooper, nsekhar, linux-mtd, linux-omap, devicetree,
linux-kernel
On Thu, Apr 07, 2016 at 01:08:31PM +0300, Roger Quadros wrote:
> OMAPs can have 2 to 4 WAITPINs that can be used as general purpose
> input if not used for memory wait state insertion.
>
> The first user will be the OMAP NAND chip to get the NAND
> read/busy status using gpiolib.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> .../bindings/memory-controllers/omap-gpmc.txt | 6 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/memory/Kconfig | 1 +
> drivers/memory/omap-gpmc.c | 117 ++++++++++++++++++---
> 3 files changed, 112 insertions(+), 12 deletions(-)
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 13/17] memory: omap-gpmc: Support general purpose input for WAITPINs
@ 2016-04-11 15:00 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 15:00 UTC (permalink / raw)
To: Roger Quadros
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
javier-0uQlZySMnqxg9hUCZPvPmw, fcooper-l0cyMroinI0,
nsekhar-l0cyMroinI0, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Thu, Apr 07, 2016 at 01:08:31PM +0300, Roger Quadros wrote:
> OMAPs can have 2 to 4 WAITPINs that can be used as general purpose
> input if not used for memory wait state insertion.
>
> The first user will be the OMAP NAND chip to get the NAND
> read/busy status using gpiolib.
>
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
> .../bindings/memory-controllers/omap-gpmc.txt | 6 ++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/memory/Kconfig | 1 +
> drivers/memory/omap-gpmc.c | 117 ++++++++++++++++++---
> 3 files changed, 112 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v6 14/17] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
If the device attached to GPMC wants to use the WAIT pin
for WAIT monitoring then we reserve it internally for
exclusive use.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 4dd1c65..784a64f 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1911,6 +1911,8 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
const char *name;
int ret, cs;
u32 val;
+ struct gpio_desc *waitpin_desc = NULL;
+ struct gpmc_device *gpmc = platform_get_drvdata(pdev);
if (of_property_read_u32(child, "reg", &cs) < 0) {
dev_err(&pdev->dev, "%s has no 'reg' property\n",
@@ -2020,16 +2022,30 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
goto err;
}
+ /* Reserve wait pin if it is required and valid */
+ if (gpmc_s.wait_on_read || gpmc_s.wait_on_write) {
+ unsigned int wait_pin = gpmc_s.wait_pin;
+
+ waitpin_desc = gpiochip_request_own_desc(&gpmc->gpio_chip,
+ wait_pin, "WAITPIN");
+ if (IS_ERR(waitpin_desc)) {
+ dev_err(&pdev->dev, "invalid wait-pin: %d\n", wait_pin);
+ ret = PTR_ERR(waitpin_desc);
+ goto err;
+ }
+ }
+
gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings");
+
ret = gpmc_cs_program_settings(cs, &gpmc_s);
if (ret < 0)
- goto err;
+ goto err_cs;
ret = gpmc_cs_set_timings(cs, &gpmc_t, &gpmc_s);
if (ret) {
dev_err(&pdev->dev, "failed to set gpmc timings for: %s\n",
child->name);
- goto err;
+ goto err_cs;
}
/* Clear limited address i.e. enable A26-A11 */
@@ -2060,6 +2076,10 @@ err_child_fail:
dev_err(&pdev->dev, "failed to create gpmc child %s\n", child->name);
ret = -ENODEV;
+err_cs:
+ if (waitpin_desc)
+ gpiochip_free_own_desc(waitpin_desc);
+
err:
gpmc_cs_free(cs);
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 14/17] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
If the device attached to GPMC wants to use the WAIT pin
for WAIT monitoring then we reserve it internally for
exclusive use.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 4dd1c65..784a64f 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1911,6 +1911,8 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
const char *name;
int ret, cs;
u32 val;
+ struct gpio_desc *waitpin_desc = NULL;
+ struct gpmc_device *gpmc = platform_get_drvdata(pdev);
if (of_property_read_u32(child, "reg", &cs) < 0) {
dev_err(&pdev->dev, "%s has no 'reg' property\n",
@@ -2020,16 +2022,30 @@ static int gpmc_probe_generic_child(struct platform_device *pdev,
goto err;
}
+ /* Reserve wait pin if it is required and valid */
+ if (gpmc_s.wait_on_read || gpmc_s.wait_on_write) {
+ unsigned int wait_pin = gpmc_s.wait_pin;
+
+ waitpin_desc = gpiochip_request_own_desc(&gpmc->gpio_chip,
+ wait_pin, "WAITPIN");
+ if (IS_ERR(waitpin_desc)) {
+ dev_err(&pdev->dev, "invalid wait-pin: %d\n", wait_pin);
+ ret = PTR_ERR(waitpin_desc);
+ goto err;
+ }
+ }
+
gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings");
+
ret = gpmc_cs_program_settings(cs, &gpmc_s);
if (ret < 0)
- goto err;
+ goto err_cs;
ret = gpmc_cs_set_timings(cs, &gpmc_t, &gpmc_s);
if (ret) {
dev_err(&pdev->dev, "failed to set gpmc timings for: %s\n",
child->name);
- goto err;
+ goto err_cs;
}
/* Clear limited address i.e. enable A26-A11 */
@@ -2060,6 +2076,10 @@ err_child_fail:
dev_err(&pdev->dev, "failed to create gpmc child %s\n", child->name);
ret = -ENODEV;
+err_cs:
+ if (waitpin_desc)
+ gpiochip_free_own_desc(waitpin_desc);
+
err:
gpmc_cs_free(cs);
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge interrupts
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
OMAPs can have 2 to 4 WAITPINs that can be used as edge triggered
interrupts if not used for memory wait state insertion.
Support these interrupts via the gpmc IRQ domain.
The gpmc IRQ domain interrupt map is:
0 - NAND_fifoevent
1 - NAND_termcount
2 - GPMC_WAIT0 edge
3 - GPMC_WAIT1 edge, and so on
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../bindings/memory-controllers/omap-gpmc.txt | 5 +-
drivers/memory/omap-gpmc.c | 106 +++++++++++++++++----
2 files changed, 92 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 97e7192..21055e2 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -33,10 +33,13 @@ Required properties:
As this will change in the future, filling correct
values here is a requirement.
- interrupt-controller: The GPMC driver implements and interrupt controller for
- the NAND events "fifoevent" and "termcount".
+ the NAND events "fifoevent" and "termcount" plus the
+ rising/falling edges on the GPMC_WAIT pins.
The interrupt number mapping is as follows
0 - NAND_fifoevent
1 - NAND_termcount
+ 2 - GPMC_WAIT0 pin edge
+ 3 - GPMC_WAIT1 pin edge, and so on.
- interrupt-cells: Must be set to 2
- gpio-controller: The GPMC driver implements a GPIO controller for the
GPMC WAIT pins that can be used as general purpose inputs.
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 784a64f..ea9c897 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -189,9 +189,7 @@
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
#define GPMC_ECC_READSYN 2 /* Reset before syndrom is read back */
-/* XXX: Only NAND irq has been considered,currently these are the only ones used
- */
-#define GPMC_NR_IRQ 2
+#define GPMC_NR_NAND_IRQS 2 /* number of NAND specific IRQs */
enum gpmc_clk_domain {
GPMC_CD_FCLK,
@@ -239,6 +237,7 @@ struct gpmc_device {
int irq;
struct irq_chip irq_chip;
struct gpio_chip gpio_chip;
+ int nirqs;
};
static struct irq_domain *gpmc_irq_domain;
@@ -1155,7 +1154,8 @@ int gpmc_get_client_irq(unsigned irq_config)
return 0;
}
- if (irq_config >= GPMC_NR_IRQ)
+ /* we restrict this to NAND IRQs only */
+ if (irq_config >= GPMC_NR_NAND_IRQS)
return 0;
return irq_create_mapping(gpmc_irq_domain, irq_config);
@@ -1165,6 +1165,10 @@ static int gpmc_irq_endis(unsigned long hwirq, bool endis)
{
u32 regval;
+ /* bits GPMC_NR_NAND_IRQS to 8 are reserved */
+ if (hwirq >= GPMC_NR_NAND_IRQS)
+ hwirq += 8 - GPMC_NR_NAND_IRQS;
+
regval = gpmc_read_reg(GPMC_IRQENABLE);
if (endis)
regval |= BIT(hwirq);
@@ -1185,9 +1189,64 @@ static void gpmc_irq_enable(struct irq_data *p)
gpmc_irq_endis(p->hwirq, true);
}
-static void gpmc_irq_noop(struct irq_data *data) { }
+static void gpmc_irq_mask(struct irq_data *d)
+{
+ gpmc_irq_endis(d->hwirq, false);
+}
+
+static void gpmc_irq_unmask(struct irq_data *d)
+{
+ gpmc_irq_endis(d->hwirq, true);
+}
+
+static void gpmc_irq_edge_config(unsigned long hwirq, bool rising_edge)
+{
+ u32 regval;
+
+ /* NAND IRQs polarity is not configurable */
+ if (hwirq < GPMC_NR_NAND_IRQS)
+ return;
+
+ /* WAITPIN starts at BIT 8 */
+ hwirq += 8 - GPMC_NR_NAND_IRQS;
+
+ regval = gpmc_read_reg(GPMC_CONFIG);
+ if (rising_edge)
+ regval &= ~BIT(hwirq);
+ else
+ regval |= BIT(hwirq);
+
+ gpmc_write_reg(GPMC_CONFIG, regval);
+}
+
+static void gpmc_irq_ack(struct irq_data *d)
+{
+ unsigned int hwirq = d->hwirq;
+
+ /* skip reserved bits */
+ if (hwirq >= GPMC_NR_NAND_IRQS)
+ hwirq += 8 - GPMC_NR_NAND_IRQS;
+
+ /* Setting bit to 1 clears (or Acks) the interrupt */
+ gpmc_write_reg(GPMC_IRQSTATUS, BIT(hwirq));
+}
+
+static int gpmc_irq_set_type(struct irq_data *d, unsigned int trigger)
+{
+ /* can't set type for NAND IRQs */
+ if (d->hwirq < GPMC_NR_NAND_IRQS)
+ return -EINVAL;
+
+ /* We can support either rising or falling edge at a time */
+ if (trigger == IRQ_TYPE_EDGE_FALLING)
+ gpmc_irq_edge_config(d->hwirq, false);
+ else if (trigger == IRQ_TYPE_EDGE_RISING)
+ gpmc_irq_edge_config(d->hwirq, true);
+ else
+ return -EINVAL;
-static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
+ return 0;
+}
static int gpmc_irq_map(struct irq_domain *d, unsigned int virq,
irq_hw_number_t hw)
@@ -1195,8 +1254,14 @@ static int gpmc_irq_map(struct irq_domain *d, unsigned int virq,
struct gpmc_device *gpmc = d->host_data;
irq_set_chip_data(virq, gpmc);
- irq_set_chip_and_handler(virq, &gpmc->irq_chip, handle_simple_irq);
- irq_modify_status(virq, IRQ_NOREQUEST, IRQ_NOAUTOEN);
+ if (hw < GPMC_NR_NAND_IRQS) {
+ irq_modify_status(virq, IRQ_NOREQUEST, IRQ_NOAUTOEN);
+ irq_set_chip_and_handler(virq, &gpmc->irq_chip,
+ handle_simple_irq);
+ } else {
+ irq_set_chip_and_handler(virq, &gpmc->irq_chip,
+ handle_edge_irq);
+ }
return 0;
}
@@ -1209,16 +1274,21 @@ static const struct irq_domain_ops gpmc_irq_domain_ops = {
static irqreturn_t gpmc_handle_irq(int irq, void *data)
{
int hwirq, virq;
- u32 regval;
+ u32 regval, regvalx;
struct gpmc_device *gpmc = data;
regval = gpmc_read_reg(GPMC_IRQSTATUS);
+ regvalx = regval;
if (!regval)
return IRQ_NONE;
- for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++) {
- if (regval & BIT(hwirq)) {
+ for (hwirq = 0; hwirq < gpmc->nirqs; hwirq++) {
+ /* skip reserved status bits */
+ if (hwirq == GPMC_NR_NAND_IRQS)
+ regvalx >>= 8 - GPMC_NR_NAND_IRQS;
+
+ if (regvalx & BIT(hwirq)) {
virq = irq_find_mapping(gpmc_irq_domain, hwirq);
if (!virq) {
dev_warn(gpmc->dev,
@@ -1248,16 +1318,15 @@ static int gpmc_setup_irq(struct gpmc_device *gpmc)
gpmc_write_reg(GPMC_IRQSTATUS, regval);
gpmc->irq_chip.name = "gpmc";
- gpmc->irq_chip.irq_startup = gpmc_irq_noop_ret;
gpmc->irq_chip.irq_enable = gpmc_irq_enable;
gpmc->irq_chip.irq_disable = gpmc_irq_disable;
- gpmc->irq_chip.irq_shutdown = gpmc_irq_noop;
- gpmc->irq_chip.irq_ack = gpmc_irq_noop;
- gpmc->irq_chip.irq_mask = gpmc_irq_noop;
- gpmc->irq_chip.irq_unmask = gpmc_irq_noop;
+ gpmc->irq_chip.irq_ack = gpmc_irq_ack;
+ gpmc->irq_chip.irq_mask = gpmc_irq_mask;
+ gpmc->irq_chip.irq_unmask = gpmc_irq_unmask;
+ gpmc->irq_chip.irq_set_type = gpmc_irq_set_type;
gpmc_irq_domain = irq_domain_add_linear(gpmc->dev->of_node,
- GPMC_NR_IRQ,
+ gpmc->nirqs,
&gpmc_irq_domain_ops,
gpmc);
if (!gpmc_irq_domain) {
@@ -1282,7 +1351,7 @@ static int gpmc_free_irq(struct gpmc_device *gpmc)
free_irq(gpmc->irq, gpmc);
- for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++)
+ for (hwirq = 0; hwirq < gpmc->nirqs; hwirq++)
irq_dispose_mapping(irq_find_mapping(gpmc_irq_domain, hwirq));
irq_domain_remove(gpmc_irq_domain);
@@ -2296,6 +2365,7 @@ static int gpmc_probe(struct platform_device *pdev)
if (rc)
goto gpio_init_failed;
+ gpmc->nirqs = GPMC_NR_NAND_IRQS + gpmc_nr_waitpins;
rc = gpmc_setup_irq(gpmc);
if (rc) {
dev_err(gpmc->dev, "gpmc_setup_irq failed\n");
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge interrupts
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
OMAPs can have 2 to 4 WAITPINs that can be used as edge triggered
interrupts if not used for memory wait state insertion.
Support these interrupts via the gpmc IRQ domain.
The gpmc IRQ domain interrupt map is:
0 - NAND_fifoevent
1 - NAND_termcount
2 - GPMC_WAIT0 edge
3 - GPMC_WAIT1 edge, and so on
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../bindings/memory-controllers/omap-gpmc.txt | 5 +-
drivers/memory/omap-gpmc.c | 106 +++++++++++++++++----
2 files changed, 92 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 97e7192..21055e2 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -33,10 +33,13 @@ Required properties:
As this will change in the future, filling correct
values here is a requirement.
- interrupt-controller: The GPMC driver implements and interrupt controller for
- the NAND events "fifoevent" and "termcount".
+ the NAND events "fifoevent" and "termcount" plus the
+ rising/falling edges on the GPMC_WAIT pins.
The interrupt number mapping is as follows
0 - NAND_fifoevent
1 - NAND_termcount
+ 2 - GPMC_WAIT0 pin edge
+ 3 - GPMC_WAIT1 pin edge, and so on.
- interrupt-cells: Must be set to 2
- gpio-controller: The GPMC driver implements a GPIO controller for the
GPMC WAIT pins that can be used as general purpose inputs.
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 784a64f..ea9c897 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -189,9 +189,7 @@
#define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
#define GPMC_ECC_READSYN 2 /* Reset before syndrom is read back */
-/* XXX: Only NAND irq has been considered,currently these are the only ones used
- */
-#define GPMC_NR_IRQ 2
+#define GPMC_NR_NAND_IRQS 2 /* number of NAND specific IRQs */
enum gpmc_clk_domain {
GPMC_CD_FCLK,
@@ -239,6 +237,7 @@ struct gpmc_device {
int irq;
struct irq_chip irq_chip;
struct gpio_chip gpio_chip;
+ int nirqs;
};
static struct irq_domain *gpmc_irq_domain;
@@ -1155,7 +1154,8 @@ int gpmc_get_client_irq(unsigned irq_config)
return 0;
}
- if (irq_config >= GPMC_NR_IRQ)
+ /* we restrict this to NAND IRQs only */
+ if (irq_config >= GPMC_NR_NAND_IRQS)
return 0;
return irq_create_mapping(gpmc_irq_domain, irq_config);
@@ -1165,6 +1165,10 @@ static int gpmc_irq_endis(unsigned long hwirq, bool endis)
{
u32 regval;
+ /* bits GPMC_NR_NAND_IRQS to 8 are reserved */
+ if (hwirq >= GPMC_NR_NAND_IRQS)
+ hwirq += 8 - GPMC_NR_NAND_IRQS;
+
regval = gpmc_read_reg(GPMC_IRQENABLE);
if (endis)
regval |= BIT(hwirq);
@@ -1185,9 +1189,64 @@ static void gpmc_irq_enable(struct irq_data *p)
gpmc_irq_endis(p->hwirq, true);
}
-static void gpmc_irq_noop(struct irq_data *data) { }
+static void gpmc_irq_mask(struct irq_data *d)
+{
+ gpmc_irq_endis(d->hwirq, false);
+}
+
+static void gpmc_irq_unmask(struct irq_data *d)
+{
+ gpmc_irq_endis(d->hwirq, true);
+}
+
+static void gpmc_irq_edge_config(unsigned long hwirq, bool rising_edge)
+{
+ u32 regval;
+
+ /* NAND IRQs polarity is not configurable */
+ if (hwirq < GPMC_NR_NAND_IRQS)
+ return;
+
+ /* WAITPIN starts at BIT 8 */
+ hwirq += 8 - GPMC_NR_NAND_IRQS;
+
+ regval = gpmc_read_reg(GPMC_CONFIG);
+ if (rising_edge)
+ regval &= ~BIT(hwirq);
+ else
+ regval |= BIT(hwirq);
+
+ gpmc_write_reg(GPMC_CONFIG, regval);
+}
+
+static void gpmc_irq_ack(struct irq_data *d)
+{
+ unsigned int hwirq = d->hwirq;
+
+ /* skip reserved bits */
+ if (hwirq >= GPMC_NR_NAND_IRQS)
+ hwirq += 8 - GPMC_NR_NAND_IRQS;
+
+ /* Setting bit to 1 clears (or Acks) the interrupt */
+ gpmc_write_reg(GPMC_IRQSTATUS, BIT(hwirq));
+}
+
+static int gpmc_irq_set_type(struct irq_data *d, unsigned int trigger)
+{
+ /* can't set type for NAND IRQs */
+ if (d->hwirq < GPMC_NR_NAND_IRQS)
+ return -EINVAL;
+
+ /* We can support either rising or falling edge at a time */
+ if (trigger == IRQ_TYPE_EDGE_FALLING)
+ gpmc_irq_edge_config(d->hwirq, false);
+ else if (trigger == IRQ_TYPE_EDGE_RISING)
+ gpmc_irq_edge_config(d->hwirq, true);
+ else
+ return -EINVAL;
-static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
+ return 0;
+}
static int gpmc_irq_map(struct irq_domain *d, unsigned int virq,
irq_hw_number_t hw)
@@ -1195,8 +1254,14 @@ static int gpmc_irq_map(struct irq_domain *d, unsigned int virq,
struct gpmc_device *gpmc = d->host_data;
irq_set_chip_data(virq, gpmc);
- irq_set_chip_and_handler(virq, &gpmc->irq_chip, handle_simple_irq);
- irq_modify_status(virq, IRQ_NOREQUEST, IRQ_NOAUTOEN);
+ if (hw < GPMC_NR_NAND_IRQS) {
+ irq_modify_status(virq, IRQ_NOREQUEST, IRQ_NOAUTOEN);
+ irq_set_chip_and_handler(virq, &gpmc->irq_chip,
+ handle_simple_irq);
+ } else {
+ irq_set_chip_and_handler(virq, &gpmc->irq_chip,
+ handle_edge_irq);
+ }
return 0;
}
@@ -1209,16 +1274,21 @@ static const struct irq_domain_ops gpmc_irq_domain_ops = {
static irqreturn_t gpmc_handle_irq(int irq, void *data)
{
int hwirq, virq;
- u32 regval;
+ u32 regval, regvalx;
struct gpmc_device *gpmc = data;
regval = gpmc_read_reg(GPMC_IRQSTATUS);
+ regvalx = regval;
if (!regval)
return IRQ_NONE;
- for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++) {
- if (regval & BIT(hwirq)) {
+ for (hwirq = 0; hwirq < gpmc->nirqs; hwirq++) {
+ /* skip reserved status bits */
+ if (hwirq == GPMC_NR_NAND_IRQS)
+ regvalx >>= 8 - GPMC_NR_NAND_IRQS;
+
+ if (regvalx & BIT(hwirq)) {
virq = irq_find_mapping(gpmc_irq_domain, hwirq);
if (!virq) {
dev_warn(gpmc->dev,
@@ -1248,16 +1318,15 @@ static int gpmc_setup_irq(struct gpmc_device *gpmc)
gpmc_write_reg(GPMC_IRQSTATUS, regval);
gpmc->irq_chip.name = "gpmc";
- gpmc->irq_chip.irq_startup = gpmc_irq_noop_ret;
gpmc->irq_chip.irq_enable = gpmc_irq_enable;
gpmc->irq_chip.irq_disable = gpmc_irq_disable;
- gpmc->irq_chip.irq_shutdown = gpmc_irq_noop;
- gpmc->irq_chip.irq_ack = gpmc_irq_noop;
- gpmc->irq_chip.irq_mask = gpmc_irq_noop;
- gpmc->irq_chip.irq_unmask = gpmc_irq_noop;
+ gpmc->irq_chip.irq_ack = gpmc_irq_ack;
+ gpmc->irq_chip.irq_mask = gpmc_irq_mask;
+ gpmc->irq_chip.irq_unmask = gpmc_irq_unmask;
+ gpmc->irq_chip.irq_set_type = gpmc_irq_set_type;
gpmc_irq_domain = irq_domain_add_linear(gpmc->dev->of_node,
- GPMC_NR_IRQ,
+ gpmc->nirqs,
&gpmc_irq_domain_ops,
gpmc);
if (!gpmc_irq_domain) {
@@ -1282,7 +1351,7 @@ static int gpmc_free_irq(struct gpmc_device *gpmc)
free_irq(gpmc->irq, gpmc);
- for (hwirq = 0; hwirq < GPMC_NR_IRQ; hwirq++)
+ for (hwirq = 0; hwirq < gpmc->nirqs; hwirq++)
irq_dispose_mapping(irq_find_mapping(gpmc_irq_domain, hwirq));
irq_domain_remove(gpmc_irq_domain);
@@ -2296,6 +2365,7 @@ static int gpmc_probe(struct platform_device *pdev)
if (rc)
goto gpio_init_failed;
+ gpmc->nirqs = GPMC_NR_NAND_IRQS + gpmc_nr_waitpins;
rc = gpmc_setup_irq(gpmc);
if (rc) {
dev_err(gpmc->dev, "gpmc_setup_irq failed\n");
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* Re: [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge interrupts
@ 2016-04-11 15:03 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 15:03 UTC (permalink / raw)
To: Roger Quadros
Cc: tony, computersforpeace, boris.brezillon, dwmw2, ezequiel,
javier, fcooper, nsekhar, linux-mtd, linux-omap, devicetree,
linux-kernel
On Thu, Apr 07, 2016 at 01:08:33PM +0300, Roger Quadros wrote:
> OMAPs can have 2 to 4 WAITPINs that can be used as edge triggered
> interrupts if not used for memory wait state insertion.
>
> Support these interrupts via the gpmc IRQ domain.
>
> The gpmc IRQ domain interrupt map is:
>
> 0 - NAND_fifoevent
> 1 - NAND_termcount
> 2 - GPMC_WAIT0 edge
> 3 - GPMC_WAIT1 edge, and so on
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> .../bindings/memory-controllers/omap-gpmc.txt | 5 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/memory/omap-gpmc.c | 106 +++++++++++++++++----
> 2 files changed, 92 insertions(+), 19 deletions(-)
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge interrupts
@ 2016-04-11 15:03 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 15:03 UTC (permalink / raw)
To: Roger Quadros
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
javier-0uQlZySMnqxg9hUCZPvPmw, fcooper-l0cyMroinI0,
nsekhar-l0cyMroinI0, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Thu, Apr 07, 2016 at 01:08:33PM +0300, Roger Quadros wrote:
> OMAPs can have 2 to 4 WAITPINs that can be used as edge triggered
> interrupts if not used for memory wait state insertion.
>
> Support these interrupts via the gpmc IRQ domain.
>
> The gpmc IRQ domain interrupt map is:
>
> 0 - NAND_fifoevent
> 1 - NAND_termcount
> 2 - GPMC_WAIT0 edge
> 3 - GPMC_WAIT1 edge, and so on
>
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> ---
> .../bindings/memory-controllers/omap-gpmc.txt | 5 +-
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/memory/omap-gpmc.c | 106 +++++++++++++++++----
> 2 files changed, 92 insertions(+), 19 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH v6 16/17] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
GPMC_STATUS register is private to the GPMC module and must not be
accessed directly by NAND driver through the gpmc_regs.
They must use gpmc_omap_get_nand_ops() instead.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 2 +-
include/linux/platform_data/mtd-nand-omap2.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index ea9c897..33d69b1 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1081,7 +1081,7 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
{
int i;
- reg->gpmc_status = gpmc_base + GPMC_STATUS;
+ reg->gpmc_status = NULL; /* deprecated */
reg->gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
reg->gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index ff27e5a..7f6de53 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -45,7 +45,6 @@ enum omap_ecc {
};
struct gpmc_nand_regs {
- void __iomem *gpmc_status;
void __iomem *gpmc_nand_command;
void __iomem *gpmc_nand_address;
void __iomem *gpmc_nand_data;
@@ -64,6 +63,8 @@ struct gpmc_nand_regs {
void __iomem *gpmc_bch_result4[GPMC_BCH_NUM_REMAINDER];
void __iomem *gpmc_bch_result5[GPMC_BCH_NUM_REMAINDER];
void __iomem *gpmc_bch_result6[GPMC_BCH_NUM_REMAINDER];
+ /* Deprecated. Do not use */
+ void __iomem *gpmc_status;
};
struct omap_nand_platform_data {
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 16/17] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
GPMC_STATUS register is private to the GPMC module and must not be
accessed directly by NAND driver through the gpmc_regs.
They must use gpmc_omap_get_nand_ops() instead.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/memory/omap-gpmc.c | 2 +-
include/linux/platform_data/mtd-nand-omap2.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index ea9c897..33d69b1 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1081,7 +1081,7 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
{
int i;
- reg->gpmc_status = gpmc_base + GPMC_STATUS;
+ reg->gpmc_status = NULL; /* deprecated */
reg->gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
reg->gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index ff27e5a..7f6de53 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -45,7 +45,6 @@ enum omap_ecc {
};
struct gpmc_nand_regs {
- void __iomem *gpmc_status;
void __iomem *gpmc_nand_command;
void __iomem *gpmc_nand_address;
void __iomem *gpmc_nand_data;
@@ -64,6 +63,8 @@ struct gpmc_nand_regs {
void __iomem *gpmc_bch_result4[GPMC_BCH_NUM_REMAINDER];
void __iomem *gpmc_bch_result5[GPMC_BCH_NUM_REMAINDER];
void __iomem *gpmc_bch_result6[GPMC_BCH_NUM_REMAINDER];
+ /* Deprecated. Do not use */
+ void __iomem *gpmc_status;
};
struct omap_nand_platform_data {
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread
* [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using gpiolib
2016-04-07 10:08 ` Roger Quadros
@ 2016-04-07 10:08 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
The GPMC WAIT pin status are now available over gpiolib.
Update the omap_dev_ready() function to use gpio instead of
directly accessing GPMC register space.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 2 ++
drivers/mtd/nand/omap2.c | 29 ++++++++++++++--------
include/linux/platform_data/mtd-nand-omap2.h | 2 +-
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index ff3215d2..3ee7e20 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -48,6 +48,7 @@ Optional properties:
locating ECC errors for BCHx algorithms. SoC devices which have
ELM hardware engines should specify this device node in .dtsi
Using ELM for ECC error correction frees some CPU cycles.
+ - rb-gpios: GPIO specifier for the ready/busy# pin.
For inline partition table parsing (optional):
@@ -78,6 +79,7 @@ Example for an AM33xx board:
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
ti,nand-xfer-type = "polled";
+ rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
gpmc,sync-clk-ps = <0>;
gpmc,cs-on-ns = <0>;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 35b8f33..e0b2b2f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -12,6 +12,7 @@
#include <linux/dmaengine.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/jiffies.h>
@@ -182,6 +183,8 @@ struct omap_nand_info {
struct nand_ecclayout oobinfo;
/* fields specific for BCHx_HW ECC scheme */
struct device *elm_dev;
+ /* NAND ready gpio */
+ struct gpio_desc *ready_gpiod;
};
static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd)
@@ -1023,21 +1026,16 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip *chip)
}
/**
- * omap_dev_ready - calls the platform specific dev_ready function
+ * omap_dev_ready - checks the NAND Ready GPIO line
* @mtd: MTD device structure
+ *
+ * Returns true if ready and false if busy.
*/
static int omap_dev_ready(struct mtd_info *mtd)
{
- unsigned int val = 0;
struct omap_nand_info *info = mtd_to_omap(mtd);
- val = readl(info->reg.gpmc_status);
-
- if ((val & 0x100) == 0x100) {
- return 1;
- } else {
- return 0;
- }
+ return gpiod_get_value(info->ready_gpiod);
}
/**
@@ -1755,7 +1753,9 @@ static int omap_nand_probe(struct platform_device *pdev)
info->gpmc_cs = pdata->cs;
info->reg = pdata->reg;
info->ecc_opt = pdata->ecc_opt;
- info->dev_ready = pdata->dev_ready;
+ if (pdata->dev_ready)
+ dev_info(&pdev->dev, "pdata->dev_ready is deprecated\n");
+
info->xfer_type = pdata->xfer_type;
info->devsize = pdata->devsize;
info->elm_of_node = pdata->elm_of_node;
@@ -1787,6 +1787,13 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
nand_chip->cmd_ctrl = omap_hwcontrol;
+ info->ready_gpiod = devm_gpiod_get_optional(&pdev->dev, "rb",
+ GPIOD_IN);
+ if (IS_ERR(info->ready_gpiod)) {
+ dev_err(dev, "failed to get ready gpio\n");
+ return PTR_ERR(info->ready_gpiod);
+ }
+
/*
* If RDY/BSY line is connected to OMAP then use the omap ready
* function and the generic nand_wait function which reads the status
@@ -1794,7 +1801,7 @@ static int omap_nand_probe(struct platform_device *pdev)
* chip delay which is slightly more than tR (AC Timing) of the NAND
* device and read status register until you get a failure or success
*/
- if (info->dev_ready) {
+ if (info->ready_gpiod) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
} else {
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index 7f6de53..17d57a1 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -71,7 +71,6 @@ struct omap_nand_platform_data {
int cs;
struct mtd_partition *parts;
int nr_parts;
- bool dev_ready;
bool flash_bbt;
enum nand_io xfer_type;
int devsize;
@@ -82,5 +81,6 @@ struct omap_nand_platform_data {
/* deprecated */
struct gpmc_nand_regs reg;
struct device_node *of_node;
+ bool dev_ready;
};
#endif
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using gpiolib
@ 2016-04-07 10:08 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-07 10:08 UTC (permalink / raw)
To: tony, computersforpeace, boris.brezillon
Cc: dwmw2, ezequiel, javier, fcooper, nsekhar, linux-mtd, linux-omap,
devicetree, linux-kernel, Roger Quadros
The GPMC WAIT pin status are now available over gpiolib.
Update the omap_dev_ready() function to use gpio instead of
directly accessing GPMC register space.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
.../devicetree/bindings/mtd/gpmc-nand.txt | 2 ++
drivers/mtd/nand/omap2.c | 29 ++++++++++++++--------
include/linux/platform_data/mtd-nand-omap2.h | 2 +-
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index ff3215d2..3ee7e20 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -48,6 +48,7 @@ Optional properties:
locating ECC errors for BCHx algorithms. SoC devices which have
ELM hardware engines should specify this device node in .dtsi
Using ELM for ECC error correction frees some CPU cycles.
+ - rb-gpios: GPIO specifier for the ready/busy# pin.
For inline partition table parsing (optional):
@@ -78,6 +79,7 @@ Example for an AM33xx board:
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
ti,nand-xfer-type = "polled";
+ rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
gpmc,sync-clk-ps = <0>;
gpmc,cs-on-ns = <0>;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 35b8f33..e0b2b2f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -12,6 +12,7 @@
#include <linux/dmaengine.h>
#include <linux/dma-mapping.h>
#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/jiffies.h>
@@ -182,6 +183,8 @@ struct omap_nand_info {
struct nand_ecclayout oobinfo;
/* fields specific for BCHx_HW ECC scheme */
struct device *elm_dev;
+ /* NAND ready gpio */
+ struct gpio_desc *ready_gpiod;
};
static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd)
@@ -1023,21 +1026,16 @@ static int omap_wait(struct mtd_info *mtd, struct nand_chip *chip)
}
/**
- * omap_dev_ready - calls the platform specific dev_ready function
+ * omap_dev_ready - checks the NAND Ready GPIO line
* @mtd: MTD device structure
+ *
+ * Returns true if ready and false if busy.
*/
static int omap_dev_ready(struct mtd_info *mtd)
{
- unsigned int val = 0;
struct omap_nand_info *info = mtd_to_omap(mtd);
- val = readl(info->reg.gpmc_status);
-
- if ((val & 0x100) == 0x100) {
- return 1;
- } else {
- return 0;
- }
+ return gpiod_get_value(info->ready_gpiod);
}
/**
@@ -1755,7 +1753,9 @@ static int omap_nand_probe(struct platform_device *pdev)
info->gpmc_cs = pdata->cs;
info->reg = pdata->reg;
info->ecc_opt = pdata->ecc_opt;
- info->dev_ready = pdata->dev_ready;
+ if (pdata->dev_ready)
+ dev_info(&pdev->dev, "pdata->dev_ready is deprecated\n");
+
info->xfer_type = pdata->xfer_type;
info->devsize = pdata->devsize;
info->elm_of_node = pdata->elm_of_node;
@@ -1787,6 +1787,13 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
nand_chip->cmd_ctrl = omap_hwcontrol;
+ info->ready_gpiod = devm_gpiod_get_optional(&pdev->dev, "rb",
+ GPIOD_IN);
+ if (IS_ERR(info->ready_gpiod)) {
+ dev_err(dev, "failed to get ready gpio\n");
+ return PTR_ERR(info->ready_gpiod);
+ }
+
/*
* If RDY/BSY line is connected to OMAP then use the omap ready
* function and the generic nand_wait function which reads the status
@@ -1794,7 +1801,7 @@ static int omap_nand_probe(struct platform_device *pdev)
* chip delay which is slightly more than tR (AC Timing) of the NAND
* device and read status register until you get a failure or success
*/
- if (info->dev_ready) {
+ if (info->ready_gpiod) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
} else {
diff --git a/include/linux/platform_data/mtd-nand-omap2.h b/include/linux/platform_data/mtd-nand-omap2.h
index 7f6de53..17d57a1 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -71,7 +71,6 @@ struct omap_nand_platform_data {
int cs;
struct mtd_partition *parts;
int nr_parts;
- bool dev_ready;
bool flash_bbt;
enum nand_io xfer_type;
int devsize;
@@ -82,5 +81,6 @@ struct omap_nand_platform_data {
/* deprecated */
struct gpmc_nand_regs reg;
struct device_node *of_node;
+ bool dev_ready;
};
#endif
--
2.5.0
^ permalink raw reply related [flat|nested] 93+ messages in thread* Re: [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using gpiolib
@ 2016-04-11 15:04 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 15:04 UTC (permalink / raw)
To: Roger Quadros
Cc: tony, computersforpeace, boris.brezillon, dwmw2, ezequiel,
javier, fcooper, nsekhar, linux-mtd, linux-omap, devicetree,
linux-kernel
On Thu, Apr 07, 2016 at 01:08:35PM +0300, Roger Quadros wrote:
> The GPMC WAIT pin status are now available over gpiolib.
> Update the omap_dev_ready() function to use gpio instead of
> directly accessing GPMC register space.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> Acked-by: Brian Norris <computersforpeace@gmail.com>
> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> .../devicetree/bindings/mtd/gpmc-nand.txt | 2 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/mtd/nand/omap2.c | 29 ++++++++++++++--------
> include/linux/platform_data/mtd-nand-omap2.h | 2 +-
> 3 files changed, 21 insertions(+), 12 deletions(-)
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using gpiolib
@ 2016-04-11 15:04 ` Rob Herring
0 siblings, 0 replies; 93+ messages in thread
From: Rob Herring @ 2016-04-11 15:04 UTC (permalink / raw)
To: Roger Quadros
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
javier-0uQlZySMnqxg9hUCZPvPmw, fcooper-l0cyMroinI0,
nsekhar-l0cyMroinI0, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Thu, Apr 07, 2016 at 01:08:35PM +0300, Roger Quadros wrote:
> The GPMC WAIT pin status are now available over gpiolib.
> Update the omap_dev_ready() function to use gpio instead of
> directly accessing GPMC register space.
>
> Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
> Acked-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/mtd/gpmc-nand.txt | 2 ++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/mtd/nand/omap2.c | 29 ++++++++++++++--------
> include/linux/platform_data/mtd-nand-omap2.h | 2 +-
> 3 files changed, 21 insertions(+), 12 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-13 21:25 ` Tony Lindgren
0 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-13 21:25 UTC (permalink / raw)
To: Roger Quadros
Cc: computersforpeace, boris.brezillon, dwmw2, ezequiel, javier,
fcooper, nsekhar, linux-mtd, linux-omap, devicetree,
linux-kernel
* Roger Quadros <rogerq@ti.com> [160407 03:10]:
> Hi,
>
> As this series has cross dependency between omap and mtd subsystems,
> I'll set up a immutable branch which omap-soc and l2-mtd must
> merge in together to avoid any conflicts/breakage during integration.
>
> Brian has acked all mtd patches. Tony needs to give his Ack for the
> gpmc driver part and then I can provide the immutable branch.
Looks good to me, please feel free to add:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-13 21:25 ` Tony Lindgren
0 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-13 21:25 UTC (permalink / raw)
To: Roger Quadros
Cc: computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
javier-0uQlZySMnqxg9hUCZPvPmw, fcooper-l0cyMroinI0,
nsekhar-l0cyMroinI0, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
* Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160407 03:10]:
> Hi,
>
> As this series has cross dependency between omap and mtd subsystems,
> I'll set up a immutable branch which omap-soc and l2-mtd must
> merge in together to avoid any conflicts/breakage during integration.
>
> Brian has acked all mtd patches. Tony needs to give his Ack for the
> gpmc driver part and then I can provide the immutable branch.
Looks good to me, please feel free to add:
Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 9:34 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-15 9:34 UTC (permalink / raw)
To: Tony Lindgren, boris.brezillon
Cc: computersforpeace, dwmw2, ezequiel, javier, fcooper, nsekhar,
linux-mtd, linux-omap, devicetree, linux-kernel
Tony & Boris,
On 14/04/16 00:25, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
>> Hi,
>>
>> As this series has cross dependency between omap and mtd subsystems,
>> I'll set up a immutable branch which omap-soc and l2-mtd must
>> merge in together to avoid any conflicts/breakage during integration.
>>
>> Brian has acked all mtd patches. Tony needs to give his Ack for the
>> gpmc driver part and then I can provide the immutable branch.
>
> Looks good to me, please feel free to add:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
I've added Tony and Rob's Acked-by tags and pushed the patches at the
below PULL request.
Please take this into omap-soc and l2-mtd trees. Thanks.
The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:
Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
are available in the git repository at:
git@github.com:rogerq/linux.git for-v4.7/gpmc-mtd-common
for you to fetch changes up to 10f22ee367c4aff7841da6a83c10445d7d6328d9:
mtd: nand: omap2: Implement NAND ready using gpiolib (2016-04-15 11:55:37 +0300)
----------------------------------------------------------------
Roger Quadros (17):
ARM: OMAP2+: gpmc: Add platform data
ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
memory: omap-gpmc: Introduce GPMC to NAND interface
memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
memory: omap-gpmc: Implement IRQ domain for NAND IRQs
mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers
mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty check
mtd: nand: omap: Copy platform data parameters to omap_nand_info data
mtd: nand: omap: Clean up device tree support
mtd: nand: omap: Update DT binding documentation
memory: omap-gpmc: Prevent mapping into 1st 16MB
memory: omap-gpmc: Move device tree binding to correct location
memory: omap-gpmc: Support general purpose input for WAITPINs
memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
memory: omap-gpmc: Support WAIT pin edge interrupts
memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs
mtd: nand: omap2: Implement NAND ready using gpiolib
Documentation/devicetree/bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} | 17 +++
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 19 +++-
arch/arm/mach-omap2/gpmc-nand.c | 7 +-
drivers/memory/Kconfig | 1 +
drivers/memory/omap-gpmc.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------
drivers/mtd/nand/omap2.c | 194 +++++++++++++++++++++++++++-------
include/linux/omap-gpmc.h | 172 ++++++------------------------
include/linux/platform_data/gpmc-omap.h | 172 ++++++++++++++++++++++++++++++
include/linux/platform_data/mtd-nand-omap2.h | 12 ++-
9 files changed, 817 insertions(+), 432 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} (89%)
create mode 100644 include/linux/platform_data/gpmc-omap.h
--
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 9:34 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-15 9:34 UTC (permalink / raw)
To: Tony Lindgren, boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
javier-0uQlZySMnqxg9hUCZPvPmw, fcooper-l0cyMroinI0,
nsekhar-l0cyMroinI0, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Tony & Boris,
On 14/04/16 00:25, Tony Lindgren wrote:
> * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160407 03:10]:
>> Hi,
>>
>> As this series has cross dependency between omap and mtd subsystems,
>> I'll set up a immutable branch which omap-soc and l2-mtd must
>> merge in together to avoid any conflicts/breakage during integration.
>>
>> Brian has acked all mtd patches. Tony needs to give his Ack for the
>> gpmc driver part and then I can provide the immutable branch.
>
> Looks good to me, please feel free to add:
>
> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
I've added Tony and Rob's Acked-by tags and pushed the patches at the
below PULL request.
Please take this into omap-soc and l2-mtd trees. Thanks.
The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:
Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)
are available in the git repository at:
git-9UaJU3cA/F/QT0dZR+AlfA@public.gmane.org:rogerq/linux.git for-v4.7/gpmc-mtd-common
for you to fetch changes up to 10f22ee367c4aff7841da6a83c10445d7d6328d9:
mtd: nand: omap2: Implement NAND ready using gpiolib (2016-04-15 11:55:37 +0300)
----------------------------------------------------------------
Roger Quadros (17):
ARM: OMAP2+: gpmc: Add platform data
ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
memory: omap-gpmc: Introduce GPMC to NAND interface
memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
memory: omap-gpmc: Implement IRQ domain for NAND IRQs
mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers
mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty check
mtd: nand: omap: Copy platform data parameters to omap_nand_info data
mtd: nand: omap: Clean up device tree support
mtd: nand: omap: Update DT binding documentation
memory: omap-gpmc: Prevent mapping into 1st 16MB
memory: omap-gpmc: Move device tree binding to correct location
memory: omap-gpmc: Support general purpose input for WAITPINs
memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
memory: omap-gpmc: Support WAIT pin edge interrupts
memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs
mtd: nand: omap2: Implement NAND ready using gpiolib
Documentation/devicetree/bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} | 17 +++
Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 19 +++-
arch/arm/mach-omap2/gpmc-nand.c | 7 +-
drivers/memory/Kconfig | 1 +
drivers/memory/omap-gpmc.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------------
drivers/mtd/nand/omap2.c | 194 +++++++++++++++++++++++++++-------
include/linux/omap-gpmc.h | 172 ++++++------------------------
include/linux/platform_data/gpmc-omap.h | 172 ++++++++++++++++++++++++++++++
include/linux/platform_data/mtd-nand-omap2.h | 12 ++-
9 files changed, 817 insertions(+), 432 deletions(-)
rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt} (89%)
create mode 100644 include/linux/platform_data/gpmc-omap.h
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 10:09 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 10:09 UTC (permalink / raw)
To: Roger Quadros, javier, fcooper, nsekhar, linux-mtd, linux-omap
Cc: Tony Lindgren, computersforpeace, dwmw2, ezequiel, devicetree,
linux-kernel
Hi Roger,
On Fri, 15 Apr 2016 12:34:04 +0300
Roger Quadros <rogerq@ti.com> wrote:
> Tony & Boris,
>
> On 14/04/16 00:25, Tony Lindgren wrote:
> > * Roger Quadros <rogerq@ti.com> [160407 03:10]:
> >> Hi,
> >>
> >> As this series has cross dependency between omap and mtd subsystems,
> >> I'll set up a immutable branch which omap-soc and l2-mtd must
> >> merge in together to avoid any conflicts/breakage during integration.
> >>
> >> Brian has acked all mtd patches. Tony needs to give his Ack for the
> >> gpmc driver part and then I can provide the immutable branch.
> >
> > Looks good to me, please feel free to add:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
> >
>
> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> below PULL request.
>
> Please take this into omap-soc and l2-mtd trees. Thanks.
I Pulled this branch into nand/next and had to resolve a few conflicts
(as you may have noticed, a few other reworks in the NAND and MTD layer
have been merged in the meantime).
It compiles, but I'm not sure it works correctly (I pushed the result
to nand/next-with-gpmc-rework [1]). Could you test it before I push this
to nand/next?
Thanks,
Boris
[1]https://github.com/linux-nand/linux/tree/nand/next-with-gpmc-rework
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 10:09 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 10:09 UTC (permalink / raw)
To: Roger Quadros, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: Tony Lindgren, computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi Roger,
On Fri, 15 Apr 2016 12:34:04 +0300
Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> Tony & Boris,
>
> On 14/04/16 00:25, Tony Lindgren wrote:
> > * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160407 03:10]:
> >> Hi,
> >>
> >> As this series has cross dependency between omap and mtd subsystems,
> >> I'll set up a immutable branch which omap-soc and l2-mtd must
> >> merge in together to avoid any conflicts/breakage during integration.
> >>
> >> Brian has acked all mtd patches. Tony needs to give his Ack for the
> >> gpmc driver part and then I can provide the immutable branch.
> >
> > Looks good to me, please feel free to add:
> >
> > Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> >
>
> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> below PULL request.
>
> Please take this into omap-soc and l2-mtd trees. Thanks.
I Pulled this branch into nand/next and had to resolve a few conflicts
(as you may have noticed, a few other reworks in the NAND and MTD layer
have been merged in the meantime).
It compiles, but I'm not sure it works correctly (I pushed the result
to nand/next-with-gpmc-rework [1]). Could you test it before I push this
to nand/next?
Thanks,
Boris
[1]https://github.com/linux-nand/linux/tree/nand/next-with-gpmc-rework
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-15 10:09 ` Boris Brezillon
@ 2016-04-15 10:54 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-15 10:54 UTC (permalink / raw)
To: Boris Brezillon, javier, fcooper, nsekhar, linux-mtd, linux-omap
Cc: Tony Lindgren, computersforpeace, dwmw2, ezequiel, devicetree,
linux-kernel
On 15/04/16 13:09, Boris Brezillon wrote:
> Hi Roger,
>
> On Fri, 15 Apr 2016 12:34:04 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> Tony & Boris,
>>
>> On 14/04/16 00:25, Tony Lindgren wrote:
>>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
>>>> Hi,
>>>>
>>>> As this series has cross dependency between omap and mtd subsystems,
>>>> I'll set up a immutable branch which omap-soc and l2-mtd must
>>>> merge in together to avoid any conflicts/breakage during integration.
>>>>
>>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
>>>> gpmc driver part and then I can provide the immutable branch.
>>>
>>> Looks good to me, please feel free to add:
>>>
>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>>
>>
>> I've added Tony and Rob's Acked-by tags and pushed the patches at the
>> below PULL request.
>>
>> Please take this into omap-soc and l2-mtd trees. Thanks.
>
> I Pulled this branch into nand/next and had to resolve a few conflicts
> (as you may have noticed, a few other reworks in the NAND and MTD layer
> have been merged in the meantime).
OK. I'm not sure how well this will play when this merges into liunx-next
via the omap-soc tree.
Instead, can you please create a non-mutable nand/base for me (which could be
today's nand/next) and I can base my branch on that and Tony can use my
branch without causing any merge-conflict in linux-next?
If this doesn't look OK please advice an alternative. Thanks.
cheers,
-roger
>
> It compiles, but I'm not sure it works correctly (I pushed the result
> to nand/next-with-gpmc-rework [1]). Could you test it before I push this
> to nand/next?
>
> Thanks,
>
> Boris
>
> [1]https://github.com/linux-nand/linux/tree/nand/next-with-gpmc-rework
>
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 10:54 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-15 10:54 UTC (permalink / raw)
To: Boris Brezillon, javier, fcooper, nsekhar, linux-mtd, linux-omap
Cc: Tony Lindgren, computersforpeace, dwmw2, ezequiel, devicetree,
linux-kernel
On 15/04/16 13:09, Boris Brezillon wrote:
> Hi Roger,
>
> On Fri, 15 Apr 2016 12:34:04 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> Tony & Boris,
>>
>> On 14/04/16 00:25, Tony Lindgren wrote:
>>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
>>>> Hi,
>>>>
>>>> As this series has cross dependency between omap and mtd subsystems,
>>>> I'll set up a immutable branch which omap-soc and l2-mtd must
>>>> merge in together to avoid any conflicts/breakage during integration.
>>>>
>>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
>>>> gpmc driver part and then I can provide the immutable branch.
>>>
>>> Looks good to me, please feel free to add:
>>>
>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>>
>>
>> I've added Tony and Rob's Acked-by tags and pushed the patches at the
>> below PULL request.
>>
>> Please take this into omap-soc and l2-mtd trees. Thanks.
>
> I Pulled this branch into nand/next and had to resolve a few conflicts
> (as you may have noticed, a few other reworks in the NAND and MTD layer
> have been merged in the meantime).
OK. I'm not sure how well this will play when this merges into liunx-next
via the omap-soc tree.
Instead, can you please create a non-mutable nand/base for me (which could be
today's nand/next) and I can base my branch on that and Tony can use my
branch without causing any merge-conflict in linux-next?
If this doesn't look OK please advice an alternative. Thanks.
cheers,
-roger
>
> It compiles, but I'm not sure it works correctly (I pushed the result
> to nand/next-with-gpmc-rework [1]). Could you test it before I push this
> to nand/next?
>
> Thanks,
>
> Boris
>
> [1]https://github.com/linux-nand/linux/tree/nand/next-with-gpmc-rework
>
>
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-15 10:54 ` Roger Quadros
@ 2016-04-15 11:12 ` Boris Brezillon
-1 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 11:12 UTC (permalink / raw)
To: Roger Quadros
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap, Tony Lindgren,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Fri, 15 Apr 2016 13:54:34 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 15/04/16 13:09, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Fri, 15 Apr 2016 12:34:04 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Tony & Boris,
> >>
> >> On 14/04/16 00:25, Tony Lindgren wrote:
> >>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
> >>>> Hi,
> >>>>
> >>>> As this series has cross dependency between omap and mtd subsystems,
> >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> >>>> merge in together to avoid any conflicts/breakage during integration.
> >>>>
> >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> >>>> gpmc driver part and then I can provide the immutable branch.
> >>>
> >>> Looks good to me, please feel free to add:
> >>>
> >>> Acked-by: Tony Lindgren <tony@atomide.com>
> >>>
> >>
> >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> >> below PULL request.
> >>
> >> Please take this into omap-soc and l2-mtd trees. Thanks.
> >
> > I Pulled this branch into nand/next and had to resolve a few conflicts
> > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > have been merged in the meantime).
>
> OK. I'm not sure how well this will play when this merges into liunx-next
> via the omap-soc tree.
>
> Instead, can you please create a non-mutable nand/base for me (which could be
> today's nand/next) and I can base my branch on that and Tony can use my
> branch without causing any merge-conflict in linux-next?
You want those patches to go through the arm-soc tree, right?
I'm not an expert, but I'd say that Tony should take those patches and
provide an immutable branch I can pull into nand/next.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 11:12 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 11:12 UTC (permalink / raw)
To: Roger Quadros
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap, Tony Lindgren,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Fri, 15 Apr 2016 13:54:34 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 15/04/16 13:09, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Fri, 15 Apr 2016 12:34:04 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Tony & Boris,
> >>
> >> On 14/04/16 00:25, Tony Lindgren wrote:
> >>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
> >>>> Hi,
> >>>>
> >>>> As this series has cross dependency between omap and mtd subsystems,
> >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> >>>> merge in together to avoid any conflicts/breakage during integration.
> >>>>
> >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> >>>> gpmc driver part and then I can provide the immutable branch.
> >>>
> >>> Looks good to me, please feel free to add:
> >>>
> >>> Acked-by: Tony Lindgren <tony@atomide.com>
> >>>
> >>
> >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> >> below PULL request.
> >>
> >> Please take this into omap-soc and l2-mtd trees. Thanks.
> >
> > I Pulled this branch into nand/next and had to resolve a few conflicts
> > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > have been merged in the meantime).
>
> OK. I'm not sure how well this will play when this merges into liunx-next
> via the omap-soc tree.
>
> Instead, can you please create a non-mutable nand/base for me (which could be
> today's nand/next) and I can base my branch on that and Tony can use my
> branch without causing any merge-conflict in linux-next?
You want those patches to go through the arm-soc tree, right?
I'm not an expert, but I'd say that Tony should take those patches and
provide an immutable branch I can pull into nand/next.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-15 10:54 ` Roger Quadros
@ 2016-04-15 11:51 ` Boris Brezillon
-1 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 11:51 UTC (permalink / raw)
To: Roger Quadros
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap, Tony Lindgren,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Roger, Tony,
On Fri, 15 Apr 2016 13:54:34 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 15/04/16 13:09, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Fri, 15 Apr 2016 12:34:04 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Tony & Boris,
> >>
> >> On 14/04/16 00:25, Tony Lindgren wrote:
> >>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
> >>>> Hi,
> >>>>
> >>>> As this series has cross dependency between omap and mtd subsystems,
> >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> >>>> merge in together to avoid any conflicts/breakage during integration.
> >>>>
> >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> >>>> gpmc driver part and then I can provide the immutable branch.
> >>>
> >>> Looks good to me, please feel free to add:
> >>>
> >>> Acked-by: Tony Lindgren <tony@atomide.com>
> >>>
> >>
> >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> >> below PULL request.
> >>
> >> Please take this into omap-soc and l2-mtd trees. Thanks.
> >
> > I Pulled this branch into nand/next and had to resolve a few conflicts
> > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > have been merged in the meantime).
>
> OK. I'm not sure how well this will play when this merges into liunx-next
> via the omap-soc tree.
>
> Instead, can you please create a non-mutable nand/base for me (which could be
> today's nand/next) and I can base my branch on that and Tony can use my
> branch without causing any merge-conflict in linux-next?
I just created a branch called nand/for-gpmc-rework based on today's
nand/next, but I'm still unsure how to proceed once you've rebased your
work on this branch?
Tony will first have to pull my immutable branch, then pull yours, and
then I'll have to pull an immutable branch from the the omap-soc tree
to get your changes into my nand/next branch (in case other patches
modify the same files before I send my PR). Am I missing something?
If I'm not, then this option looks over-complicated to me.
ITOH, if we decide to let your patches go through the nand or omap-soc
tree, only one immutable branch will be created, and either the nand or
omap-soc maintainer (depending on who takes the patches) will have to
pull it into its -next branch.
I'm quite new to all this merging process, so don't hesitate to correct
me if I'm wrong.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 11:51 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 11:51 UTC (permalink / raw)
To: Roger Quadros
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap, Tony Lindgren,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Roger, Tony,
On Fri, 15 Apr 2016 13:54:34 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 15/04/16 13:09, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Fri, 15 Apr 2016 12:34:04 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Tony & Boris,
> >>
> >> On 14/04/16 00:25, Tony Lindgren wrote:
> >>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
> >>>> Hi,
> >>>>
> >>>> As this series has cross dependency between omap and mtd subsystems,
> >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> >>>> merge in together to avoid any conflicts/breakage during integration.
> >>>>
> >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> >>>> gpmc driver part and then I can provide the immutable branch.
> >>>
> >>> Looks good to me, please feel free to add:
> >>>
> >>> Acked-by: Tony Lindgren <tony@atomide.com>
> >>>
> >>
> >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> >> below PULL request.
> >>
> >> Please take this into omap-soc and l2-mtd trees. Thanks.
> >
> > I Pulled this branch into nand/next and had to resolve a few conflicts
> > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > have been merged in the meantime).
>
> OK. I'm not sure how well this will play when this merges into liunx-next
> via the omap-soc tree.
>
> Instead, can you please create a non-mutable nand/base for me (which could be
> today's nand/next) and I can base my branch on that and Tony can use my
> branch without causing any merge-conflict in linux-next?
I just created a branch called nand/for-gpmc-rework based on today's
nand/next, but I'm still unsure how to proceed once you've rebased your
work on this branch?
Tony will first have to pull my immutable branch, then pull yours, and
then I'll have to pull an immutable branch from the the omap-soc tree
to get your changes into my nand/next branch (in case other patches
modify the same files before I send my PR). Am I missing something?
If I'm not, then this option looks over-complicated to me.
ITOH, if we decide to let your patches go through the nand or omap-soc
tree, only one immutable branch will be created, and either the nand or
omap-soc maintainer (depending on who takes the patches) will have to
pull it into its -next branch.
I'm quite new to all this merging process, so don't hesitate to correct
me if I'm wrong.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-15 11:51 ` Boris Brezillon
@ 2016-04-15 15:41 ` Tony Lindgren
-1 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-15 15:41 UTC (permalink / raw)
To: Boris Brezillon
Cc: Roger Quadros, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
* Boris Brezillon <boris.brezillon@free-electrons.com> [160415 04:52]:
> Roger, Tony,
>
> On Fri, 15 Apr 2016 13:54:34 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
> > On 15/04/16 13:09, Boris Brezillon wrote:
> > > Hi Roger,
> > >
> > > On Fri, 15 Apr 2016 12:34:04 +0300
> > > Roger Quadros <rogerq@ti.com> wrote:
> > >
> > >> Tony & Boris,
> > >>
> > >> On 14/04/16 00:25, Tony Lindgren wrote:
> > >>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
> > >>>> Hi,
> > >>>>
> > >>>> As this series has cross dependency between omap and mtd subsystems,
> > >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> > >>>> merge in together to avoid any conflicts/breakage during integration.
> > >>>>
> > >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> > >>>> gpmc driver part and then I can provide the immutable branch.
> > >>>
> > >>> Looks good to me, please feel free to add:
> > >>>
> > >>> Acked-by: Tony Lindgren <tony@atomide.com>
> > >>>
> > >>
> > >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> > >> below PULL request.
> > >>
> > >> Please take this into omap-soc and l2-mtd trees. Thanks.
> > >
> > > I Pulled this branch into nand/next and had to resolve a few conflicts
> > > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > > have been merged in the meantime).
> >
> > OK. I'm not sure how well this will play when this merges into liunx-next
> > via the omap-soc tree.
> >
> > Instead, can you please create a non-mutable nand/base for me (which could be
> > today's nand/next) and I can base my branch on that and Tony can use my
> > branch without causing any merge-conflict in linux-next?
>
> I just created a branch called nand/for-gpmc-rework based on today's
> nand/next, but I'm still unsure how to proceed once you've rebased your
> work on this branch?
>
> Tony will first have to pull my immutable branch, then pull yours, and
> then I'll have to pull an immutable branch from the the omap-soc tree
> to get your changes into my nand/next branch (in case other patches
> modify the same files before I send my PR). Am I missing something?
> If I'm not, then this option looks over-complicated to me.
Well why don't you merge it all via NAND then? I'm not seeing
any merge conflicts with the arch/arm/mach-omap* code.
> ITOH, if we decide to let your patches go through the nand or omap-soc
> tree, only one immutable branch will be created, and either the nand or
> omap-soc maintainer (depending on who takes the patches) will have to
> pull it into its -next branch.
>
> I'm quite new to all this merging process, so don't hesitate to correct
> me if I'm wrong.
Well the rules are that if something agreed to be immutable, then
it will never get redone. And the immutable branch should be based
on the absolute minimal set of patches against some earlier tag,
usually -rc1 is a good one. This avoids other tree to need to pull
in a huge amount of changes from other trees just to avoid merge
conflicts.
Regards,
Tony
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 15:41 ` Tony Lindgren
0 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-15 15:41 UTC (permalink / raw)
To: Boris Brezillon
Cc: Roger Quadros, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
* Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> [160415 04:52]:
> Roger, Tony,
>
> On Fri, 15 Apr 2016 13:54:34 +0300
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
>
> > On 15/04/16 13:09, Boris Brezillon wrote:
> > > Hi Roger,
> > >
> > > On Fri, 15 Apr 2016 12:34:04 +0300
> > > Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > >
> > >> Tony & Boris,
> > >>
> > >> On 14/04/16 00:25, Tony Lindgren wrote:
> > >>> * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160407 03:10]:
> > >>>> Hi,
> > >>>>
> > >>>> As this series has cross dependency between omap and mtd subsystems,
> > >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> > >>>> merge in together to avoid any conflicts/breakage during integration.
> > >>>>
> > >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> > >>>> gpmc driver part and then I can provide the immutable branch.
> > >>>
> > >>> Looks good to me, please feel free to add:
> > >>>
> > >>> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > >>>
> > >>
> > >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> > >> below PULL request.
> > >>
> > >> Please take this into omap-soc and l2-mtd trees. Thanks.
> > >
> > > I Pulled this branch into nand/next and had to resolve a few conflicts
> > > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > > have been merged in the meantime).
> >
> > OK. I'm not sure how well this will play when this merges into liunx-next
> > via the omap-soc tree.
> >
> > Instead, can you please create a non-mutable nand/base for me (which could be
> > today's nand/next) and I can base my branch on that and Tony can use my
> > branch without causing any merge-conflict in linux-next?
>
> I just created a branch called nand/for-gpmc-rework based on today's
> nand/next, but I'm still unsure how to proceed once you've rebased your
> work on this branch?
>
> Tony will first have to pull my immutable branch, then pull yours, and
> then I'll have to pull an immutable branch from the the omap-soc tree
> to get your changes into my nand/next branch (in case other patches
> modify the same files before I send my PR). Am I missing something?
> If I'm not, then this option looks over-complicated to me.
Well why don't you merge it all via NAND then? I'm not seeing
any merge conflicts with the arch/arm/mach-omap* code.
> ITOH, if we decide to let your patches go through the nand or omap-soc
> tree, only one immutable branch will be created, and either the nand or
> omap-soc maintainer (depending on who takes the patches) will have to
> pull it into its -next branch.
>
> I'm quite new to all this merging process, so don't hesitate to correct
> me if I'm wrong.
Well the rules are that if something agreed to be immutable, then
it will never get redone. And the immutable branch should be based
on the absolute minimal set of patches against some earlier tag,
usually -rc1 is a good one. This avoids other tree to need to pull
in a huge amount of changes from other trees just to avoid merge
conflicts.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 16:05 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 16:05 UTC (permalink / raw)
To: Tony Lindgren
Cc: Roger Quadros, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Hi Tony,
On Fri, 15 Apr 2016 08:41:40 -0700
Tony Lindgren <tony@atomide.com> wrote:
> * Boris Brezillon <boris.brezillon@free-electrons.com> [160415 04:52]:
> > Roger, Tony,
> >
> > On Fri, 15 Apr 2016 13:54:34 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> > > On 15/04/16 13:09, Boris Brezillon wrote:
> > > > Hi Roger,
> > > >
> > > > On Fri, 15 Apr 2016 12:34:04 +0300
> > > > Roger Quadros <rogerq@ti.com> wrote:
> > > >
> > > >> Tony & Boris,
> > > >>
> > > >> On 14/04/16 00:25, Tony Lindgren wrote:
> > > >>> * Roger Quadros <rogerq@ti.com> [160407 03:10]:
> > > >>>> Hi,
> > > >>>>
> > > >>>> As this series has cross dependency between omap and mtd subsystems,
> > > >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> > > >>>> merge in together to avoid any conflicts/breakage during integration.
> > > >>>>
> > > >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> > > >>>> gpmc driver part and then I can provide the immutable branch.
> > > >>>
> > > >>> Looks good to me, please feel free to add:
> > > >>>
> > > >>> Acked-by: Tony Lindgren <tony@atomide.com>
> > > >>>
> > > >>
> > > >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> > > >> below PULL request.
> > > >>
> > > >> Please take this into omap-soc and l2-mtd trees. Thanks.
> > > >
> > > > I Pulled this branch into nand/next and had to resolve a few conflicts
> > > > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > > > have been merged in the meantime).
> > >
> > > OK. I'm not sure how well this will play when this merges into liunx-next
> > > via the omap-soc tree.
> > >
> > > Instead, can you please create a non-mutable nand/base for me (which could be
> > > today's nand/next) and I can base my branch on that and Tony can use my
> > > branch without causing any merge-conflict in linux-next?
> >
> > I just created a branch called nand/for-gpmc-rework based on today's
> > nand/next, but I'm still unsure how to proceed once you've rebased your
> > work on this branch?
> >
> > Tony will first have to pull my immutable branch, then pull yours, and
> > then I'll have to pull an immutable branch from the the omap-soc tree
> > to get your changes into my nand/next branch (in case other patches
> > modify the same files before I send my PR). Am I missing something?
> > If I'm not, then this option looks over-complicated to me.
>
> Well why don't you merge it all via NAND then? I'm not seeing
> any merge conflicts with the arch/arm/mach-omap* code.
I'm perfectly fine with that. Actually, that's what I first did (see the
nand/next-with-gpmc-rework I asked Roger to validate).
Roger, since you don't have any dependencies on omap stuff added after
4.6-rc1, I could even rebase your patches on top of nand/next to avoid
this merge commit (and the associated conflict resolution).
>
> > ITOH, if we decide to let your patches go through the nand or omap-soc
> > tree, only one immutable branch will be created, and either the nand or
> > omap-soc maintainer (depending on who takes the patches) will have to
> > pull it into its -next branch.
> >
> > I'm quite new to all this merging process, so don't hesitate to correct
> > me if I'm wrong.
>
> Well the rules are that if something agreed to be immutable, then
> it will never get redone. And the immutable branch should be based
> on the absolute minimal set of patches against some earlier tag,
> usually -rc1 is a good one. This avoids other tree to need to pull
> in a huge amount of changes from other trees just to avoid merge
> conflicts.
How would you do it in this particular case. Say I have to provide you
with an immutable branch, it should only contain Roger's patches, right?
But this also means this immutable branch has to be pulled into my
nand/next branch before all other changes touching the same set of
files, which in turn means that I'll have to rebase and push -f my
nand/next branch (which I'd like to avoid).
Or should I just pull this immutable branch in my current nand/next and
let you pull the same immutable branch in omap-soc. I mean, would this
prevent conflicts when our branches are merged into linux-next, no
matter the order.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 16:05 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-15 16:05 UTC (permalink / raw)
To: Tony Lindgren
Cc: Roger Quadros, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi Tony,
On Fri, 15 Apr 2016 08:41:40 -0700
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> * Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> [160415 04:52]:
> > Roger, Tony,
> >
> > On Fri, 15 Apr 2016 13:54:34 +0300
> > Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> >
> > > On 15/04/16 13:09, Boris Brezillon wrote:
> > > > Hi Roger,
> > > >
> > > > On Fri, 15 Apr 2016 12:34:04 +0300
> > > > Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > >
> > > >> Tony & Boris,
> > > >>
> > > >> On 14/04/16 00:25, Tony Lindgren wrote:
> > > >>> * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160407 03:10]:
> > > >>>> Hi,
> > > >>>>
> > > >>>> As this series has cross dependency between omap and mtd subsystems,
> > > >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> > > >>>> merge in together to avoid any conflicts/breakage during integration.
> > > >>>>
> > > >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> > > >>>> gpmc driver part and then I can provide the immutable branch.
> > > >>>
> > > >>> Looks good to me, please feel free to add:
> > > >>>
> > > >>> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > >>>
> > > >>
> > > >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> > > >> below PULL request.
> > > >>
> > > >> Please take this into omap-soc and l2-mtd trees. Thanks.
> > > >
> > > > I Pulled this branch into nand/next and had to resolve a few conflicts
> > > > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > > > have been merged in the meantime).
> > >
> > > OK. I'm not sure how well this will play when this merges into liunx-next
> > > via the omap-soc tree.
> > >
> > > Instead, can you please create a non-mutable nand/base for me (which could be
> > > today's nand/next) and I can base my branch on that and Tony can use my
> > > branch without causing any merge-conflict in linux-next?
> >
> > I just created a branch called nand/for-gpmc-rework based on today's
> > nand/next, but I'm still unsure how to proceed once you've rebased your
> > work on this branch?
> >
> > Tony will first have to pull my immutable branch, then pull yours, and
> > then I'll have to pull an immutable branch from the the omap-soc tree
> > to get your changes into my nand/next branch (in case other patches
> > modify the same files before I send my PR). Am I missing something?
> > If I'm not, then this option looks over-complicated to me.
>
> Well why don't you merge it all via NAND then? I'm not seeing
> any merge conflicts with the arch/arm/mach-omap* code.
I'm perfectly fine with that. Actually, that's what I first did (see the
nand/next-with-gpmc-rework I asked Roger to validate).
Roger, since you don't have any dependencies on omap stuff added after
4.6-rc1, I could even rebase your patches on top of nand/next to avoid
this merge commit (and the associated conflict resolution).
>
> > ITOH, if we decide to let your patches go through the nand or omap-soc
> > tree, only one immutable branch will be created, and either the nand or
> > omap-soc maintainer (depending on who takes the patches) will have to
> > pull it into its -next branch.
> >
> > I'm quite new to all this merging process, so don't hesitate to correct
> > me if I'm wrong.
>
> Well the rules are that if something agreed to be immutable, then
> it will never get redone. And the immutable branch should be based
> on the absolute minimal set of patches against some earlier tag,
> usually -rc1 is a good one. This avoids other tree to need to pull
> in a huge amount of changes from other trees just to avoid merge
> conflicts.
How would you do it in this particular case. Say I have to provide you
with an immutable branch, it should only contain Roger's patches, right?
But this also means this immutable branch has to be pulled into my
nand/next branch before all other changes touching the same set of
files, which in turn means that I'll have to rebase and push -f my
nand/next branch (which I'd like to avoid).
Or should I just pull this immutable branch in my current nand/next and
let you pull the same immutable branch in omap-soc. I mean, would this
prevent conflicts when our branches are merged into linux-next, no
matter the order.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-15 16:05 ` Boris Brezillon
@ 2016-04-15 16:19 ` Tony Lindgren
-1 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-15 16:19 UTC (permalink / raw)
To: Boris Brezillon
Cc: Roger Quadros, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
* Boris Brezillon <boris.brezillon@free-electrons.com> [160415 09:06]:
> On Fri, 15 Apr 2016 08:41:40 -0700
> Tony Lindgren <tony@atomide.com> wrote:
> > Well the rules are that if something agreed to be immutable, then
> > it will never get redone. And the immutable branch should be based
> > on the absolute minimal set of patches against some earlier tag,
> > usually -rc1 is a good one. This avoids other tree to need to pull
> > in a huge amount of changes from other trees just to avoid merge
> > conflicts.
>
> How would you do it in this particular case. Say I have to provide you
> with an immutable branch, it should only contain Roger's patches, right?
Well ideally it would be just minimal NAND related changes
branch against v4.6-rc1. Then if Roger has a dependency to
that, Roger can pull it in.
Then Roger would make a branch for the GPMC changes against
your minimal NAND branch.
Then if there were non-trivial merge conflicts, I could pull
in Roger's GPMC branch as needed.
But in this case, it seems you can just merge everything via
the NAND tree and problem solved.
> But this also means this immutable branch has to be pulled into my
> nand/next branch before all other changes touching the same set of
> files, which in turn means that I'll have to rebase and push -f my
> nand/next branch (which I'd like to avoid).
Yeah let's not do rebases, there should be no need for it.
> Or should I just pull this immutable branch in my current nand/next and
> let you pull the same immutable branch in omap-soc. I mean, would this
> prevent conflicts when our branches are merged into linux-next, no
> matter the order.
Ideally just one or more branches with just minimal changes in
them against -rc1. But you may have other dependencies in
your NAND tree so that may no longer be doable :) Usually if
I merge something that may need to get merged into other
branches, I just apply them into a separate branch against -rc1
to start with, then merge that branch in.
Regards,
Tony
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-15 16:19 ` Tony Lindgren
0 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-15 16:19 UTC (permalink / raw)
To: Boris Brezillon
Cc: Roger Quadros, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
* Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> [160415 09:06]:
> On Fri, 15 Apr 2016 08:41:40 -0700
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > Well the rules are that if something agreed to be immutable, then
> > it will never get redone. And the immutable branch should be based
> > on the absolute minimal set of patches against some earlier tag,
> > usually -rc1 is a good one. This avoids other tree to need to pull
> > in a huge amount of changes from other trees just to avoid merge
> > conflicts.
>
> How would you do it in this particular case. Say I have to provide you
> with an immutable branch, it should only contain Roger's patches, right?
Well ideally it would be just minimal NAND related changes
branch against v4.6-rc1. Then if Roger has a dependency to
that, Roger can pull it in.
Then Roger would make a branch for the GPMC changes against
your minimal NAND branch.
Then if there were non-trivial merge conflicts, I could pull
in Roger's GPMC branch as needed.
But in this case, it seems you can just merge everything via
the NAND tree and problem solved.
> But this also means this immutable branch has to be pulled into my
> nand/next branch before all other changes touching the same set of
> files, which in turn means that I'll have to rebase and push -f my
> nand/next branch (which I'd like to avoid).
Yeah let's not do rebases, there should be no need for it.
> Or should I just pull this immutable branch in my current nand/next and
> let you pull the same immutable branch in omap-soc. I mean, would this
> prevent conflicts when our branches are merged into linux-next, no
> matter the order.
Ideally just one or more branches with just minimal changes in
them against -rc1. But you may have other dependencies in
your NAND tree so that may no longer be doable :) Usually if
I merge something that may need to get merged into other
branches, I just apply them into a separate branch against -rc1
to start with, then merge that branch in.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-15 16:19 ` Tony Lindgren
(?)
@ 2016-04-16 8:57 ` Boris Brezillon
2016-04-18 12:31 ` Roger Quadros
-1 siblings, 1 reply; 93+ messages in thread
From: Boris Brezillon @ 2016-04-16 8:57 UTC (permalink / raw)
To: Tony Lindgren
Cc: Roger Quadros, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Fri, 15 Apr 2016 09:19:51 -0700
Tony Lindgren <tony@atomide.com> wrote:
>
> > Or should I just pull this immutable branch in my current nand/next and
> > let you pull the same immutable branch in omap-soc. I mean, would this
> > prevent conflicts when our branches are merged into linux-next, no
> > matter the order.
>
> Ideally just one or more branches with just minimal changes in
> them against -rc1. But you may have other dependencies in
> your NAND tree so that may no longer be doable :) Usually if
> I merge something that may need to get merged into other
> branches, I just apply them into a separate branch against -rc1
> to start with, then merge that branch in.
Okay, in this case, that's pretty much what I did from the beginning,
except the immutable branch was provided by Roger (based on 4.6-rc1).
Thanks for this detailed explanation, I'll try to remember that when
I'll need to provide an immutable branch for another subsystem.
Roger, my request remains, could you check/test my conflict resolution
(branch nand/next-with-gpmc-rework)?
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-16 8:57 ` Boris Brezillon
@ 2016-04-18 12:31 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 12:31 UTC (permalink / raw)
To: Boris Brezillon, Tony Lindgren
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 16/04/16 11:57, Boris Brezillon wrote:
> On Fri, 15 Apr 2016 09:19:51 -0700
> Tony Lindgren <tony@atomide.com> wrote:
>
>>
>>> Or should I just pull this immutable branch in my current nand/next and
>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>> prevent conflicts when our branches are merged into linux-next, no
>>> matter the order.
>>
>> Ideally just one or more branches with just minimal changes in
>> them against -rc1. But you may have other dependencies in
>> your NAND tree so that may no longer be doable :) Usually if
>> I merge something that may need to get merged into other
>> branches, I just apply them into a separate branch against -rc1
>> to start with, then merge that branch in.
>
> Okay, in this case, that's pretty much what I did from the beginning,
> except the immutable branch was provided by Roger (based on 4.6-rc1).
> Thanks for this detailed explanation, I'll try to remember that when
> I'll need to provide an immutable branch for another subsystem.
>
> Roger, my request remains, could you check/test my conflict resolution
> (branch nand/next-with-gpmc-rework)?
I couldn't test that branch yet as nand/next is broken on omap platforms
(at least on dra7-evm).
The commit where it breaks is:
a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
I'm trying to figure out what went wrong there. Failure log below.
--cheers,
-roger
== attaching ubi to mtd9
[ 27.173973] ubi0: attaching mtd9
[ 27.178311] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.184828] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.191324] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ 27.203378] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.209860] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.216388] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ 27.228468] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.234976] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.241471] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ 27.253802] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.260278] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.266812] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes
[ 27.277254] CPU: 0 PID: 2032 Comm: ubiattach Not tainted 4.6.0-rc1-00053-ga662ef4 #625
[ 27.285549] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 27.291949] [<c010feec>] (unwind_backtrace) from [<c010c110>] (show_stack+0x10/0x14)
[ 27.300083] [<c010c110>] (show_stack) from [<c0470f24>] (dump_stack+0xac/0xe0)
[ 27.307664] [<c0470f24>] (dump_stack) from [<c05a5f8c>] (ubi_io_read+0x11c/0x2fc)
[ 27.315511] [<c05a5f8c>] (ubi_io_read) from [<c05a6388>] (ubi_io_read_ec_hdr+0x44/0x228)
[ 27.323989] [<c05a6388>] (ubi_io_read_ec_hdr) from [<c05aaef8>] (ubi_attach+0x138/0x149c)
[ 27.332579] [<c05aaef8>] (ubi_attach) from [<c059fc78>] (ubi_attach_mtd_dev+0x3d0/0xbe4)
[ 27.341063] [<c059fc78>] (ubi_attach_mtd_dev) from [<c05a15d4>] (ctrl_cdev_ioctl+0xe4/0x224)
[ 27.349928] [<c05a15d4>] (ctrl_cdev_ioctl) from [<c029e380>] (do_vfs_ioctl+0x90/0xa2c)
[ 27.358242] [<c029e380>] (do_vfs_ioctl) from [<c029ed88>] (SyS_ioctl+0x6c/0x7c)
[ 27.365910] [<c029ed88>] (SyS_ioctl) from [<c0107840>] (ret_fast_syscall+0x0/0x1c)
[ 27.374541] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.381025] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.387551] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read only 512 bytes, retry
[ 27.399953] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.406465] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.412950] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read only 512 bytes, retry
[ 27.425349] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.431837] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.438356] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read only 512 bytes, retry
[ 27.450735] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.457243] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.463739] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read 512 bytes
[ 27.474526] CPU: 0 PID: 2032 Comm: ubiattach Not tainted 4.6.0-rc1-00053-ga662ef4 #625
[ 27.482824] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 27.489218] [<c010feec>] (unwind_backtrace) from [<c010c110>] (show_stack+0x10/0x14)
[ 27.497348] [<c010c110>] (show_stack) from [<c0470f24>] (dump_stack+0xac/0xe0)
[ 27.504923] [<c0470f24>] (dump_stack) from [<c05a5f8c>] (ubi_io_read+0x11c/0x2fc)
[ 27.512772] [<c05a5f8c>] (ubi_io_read) from [<c05a65b8>] (ubi_io_read_vid_hdr+0x4c/0x230)
[ 27.521355] [<c05a65b8>] (ubi_io_read_vid_hdr) from [<c05ab04c>] (ubi_attach+0x28c/0x149c)
[ 27.530024] [<c05ab04c>] (ubi_attach) from [<c059fc78>] (ubi_attach_mtd_dev+0x3d0/0xbe4)
[ 27.538517] [<c059fc78>] (ubi_attach_mtd_dev) from [<c05a15d4>] (ctrl_cdev_ioctl+0xe4/0x224)
[ 27.547409] [<c05a15d4>] (ctrl_cdev_ioctl) from [<c029e380>] (do_vfs_ioctl+0x90/0xa2c)
[ 27.555736] [<c029e380>] (do_vfs_ioctl) from [<c029ed88>] (SyS_ioctl+0x6c/0x7c)
[ 27.563415] [<c029ed88>] (SyS_ioctl) from [<c0107840>] (ret_fast_syscall+0x0/0x1c)
[ 27.572208] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.579160] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.586560] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.593311] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.600038] omap2-nand omap2-nand.0: uncorrectable bit-flips found
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 12:31 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 12:31 UTC (permalink / raw)
To: Boris Brezillon, Tony Lindgren
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 16/04/16 11:57, Boris Brezillon wrote:
> On Fri, 15 Apr 2016 09:19:51 -0700
> Tony Lindgren <tony@atomide.com> wrote:
>
>>
>>> Or should I just pull this immutable branch in my current nand/next and
>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>> prevent conflicts when our branches are merged into linux-next, no
>>> matter the order.
>>
>> Ideally just one or more branches with just minimal changes in
>> them against -rc1. But you may have other dependencies in
>> your NAND tree so that may no longer be doable :) Usually if
>> I merge something that may need to get merged into other
>> branches, I just apply them into a separate branch against -rc1
>> to start with, then merge that branch in.
>
> Okay, in this case, that's pretty much what I did from the beginning,
> except the immutable branch was provided by Roger (based on 4.6-rc1).
> Thanks for this detailed explanation, I'll try to remember that when
> I'll need to provide an immutable branch for another subsystem.
>
> Roger, my request remains, could you check/test my conflict resolution
> (branch nand/next-with-gpmc-rework)?
I couldn't test that branch yet as nand/next is broken on omap platforms
(at least on dra7-evm).
The commit where it breaks is:
a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
I'm trying to figure out what went wrong there. Failure log below.
--cheers,
-roger
== attaching ubi to mtd9
[ 27.173973] ubi0: attaching mtd9
[ 27.178311] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.184828] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.191324] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ 27.203378] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.209860] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.216388] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ 27.228468] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.234976] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.241471] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read only 64 bytes, retry
[ 27.253802] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.260278] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.266812] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes
[ 27.277254] CPU: 0 PID: 2032 Comm: ubiattach Not tainted 4.6.0-rc1-00053-ga662ef4 #625
[ 27.285549] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 27.291949] [<c010feec>] (unwind_backtrace) from [<c010c110>] (show_stack+0x10/0x14)
[ 27.300083] [<c010c110>] (show_stack) from [<c0470f24>] (dump_stack+0xac/0xe0)
[ 27.307664] [<c0470f24>] (dump_stack) from [<c05a5f8c>] (ubi_io_read+0x11c/0x2fc)
[ 27.315511] [<c05a5f8c>] (ubi_io_read) from [<c05a6388>] (ubi_io_read_ec_hdr+0x44/0x228)
[ 27.323989] [<c05a6388>] (ubi_io_read_ec_hdr) from [<c05aaef8>] (ubi_attach+0x138/0x149c)
[ 27.332579] [<c05aaef8>] (ubi_attach) from [<c059fc78>] (ubi_attach_mtd_dev+0x3d0/0xbe4)
[ 27.341063] [<c059fc78>] (ubi_attach_mtd_dev) from [<c05a15d4>] (ctrl_cdev_ioctl+0xe4/0x224)
[ 27.349928] [<c05a15d4>] (ctrl_cdev_ioctl) from [<c029e380>] (do_vfs_ioctl+0x90/0xa2c)
[ 27.358242] [<c029e380>] (do_vfs_ioctl) from [<c029ed88>] (SyS_ioctl+0x6c/0x7c)
[ 27.365910] [<c029ed88>] (SyS_ioctl) from [<c0107840>] (ret_fast_syscall+0x0/0x1c)
[ 27.374541] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.381025] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.387551] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read only 512 bytes, retry
[ 27.399953] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.406465] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.412950] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read only 512 bytes, retry
[ 27.425349] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.431837] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.438356] ubi0 warning: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read only 512 bytes, retry
[ 27.450735] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.457243] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.463739] ubi0 error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read 512 bytes
[ 27.474526] CPU: 0 PID: 2032 Comm: ubiattach Not tainted 4.6.0-rc1-00053-ga662ef4 #625
[ 27.482824] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 27.489218] [<c010feec>] (unwind_backtrace) from [<c010c110>] (show_stack+0x10/0x14)
[ 27.497348] [<c010c110>] (show_stack) from [<c0470f24>] (dump_stack+0xac/0xe0)
[ 27.504923] [<c0470f24>] (dump_stack) from [<c05a5f8c>] (ubi_io_read+0x11c/0x2fc)
[ 27.512772] [<c05a5f8c>] (ubi_io_read) from [<c05a65b8>] (ubi_io_read_vid_hdr+0x4c/0x230)
[ 27.521355] [<c05a65b8>] (ubi_io_read_vid_hdr) from [<c05ab04c>] (ubi_attach+0x28c/0x149c)
[ 27.530024] [<c05ab04c>] (ubi_attach) from [<c059fc78>] (ubi_attach_mtd_dev+0x3d0/0xbe4)
[ 27.538517] [<c059fc78>] (ubi_attach_mtd_dev) from [<c05a15d4>] (ctrl_cdev_ioctl+0xe4/0x224)
[ 27.547409] [<c05a15d4>] (ctrl_cdev_ioctl) from [<c029e380>] (do_vfs_ioctl+0x90/0xa2c)
[ 27.555736] [<c029e380>] (do_vfs_ioctl) from [<c029ed88>] (SyS_ioctl+0x6c/0x7c)
[ 27.563415] [<c029ed88>] (SyS_ioctl) from [<c0107840>] (ret_fast_syscall+0x0/0x1c)
[ 27.572208] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.579160] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.586560] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.593311] omap2-nand omap2-nand.0: uncorrectable bit-flips found
[ 27.600038] omap2-nand omap2-nand.0: uncorrectable bit-flips found
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-18 12:31 ` Roger Quadros
@ 2016-04-18 12:52 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 12:52 UTC (permalink / raw)
To: Boris Brezillon, Tony Lindgren
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 18/04/16 15:31, Roger Quadros wrote:
> On 16/04/16 11:57, Boris Brezillon wrote:
>> On Fri, 15 Apr 2016 09:19:51 -0700
>> Tony Lindgren <tony@atomide.com> wrote:
>>
>>>
>>>> Or should I just pull this immutable branch in my current nand/next and
>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>> prevent conflicts when our branches are merged into linux-next, no
>>>> matter the order.
>>>
>>> Ideally just one or more branches with just minimal changes in
>>> them against -rc1. But you may have other dependencies in
>>> your NAND tree so that may no longer be doable :) Usually if
>>> I merge something that may need to get merged into other
>>> branches, I just apply them into a separate branch against -rc1
>>> to start with, then merge that branch in.
>>
>> Okay, in this case, that's pretty much what I did from the beginning,
>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>> Thanks for this detailed explanation, I'll try to remember that when
>> I'll need to provide an immutable branch for another subsystem.
>>
>> Roger, my request remains, could you check/test my conflict resolution
>> (branch nand/next-with-gpmc-rework)?
>
> I couldn't test that branch yet as nand/next is broken on omap platforms
> (at least on dra7-evm).
>
> The commit where it breaks is:
> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>
> I'm trying to figure out what went wrong there. Failure log below.
OK. I was able to fix it when at commit a662ef4 with the below patch.
Looks like we need to read exactly the ECC bytes through the ECC engine and not
the entire OOB region.
--cheers,
-oger
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index e622a1b..46b61d2 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
chip->read_buf(mtd, buf, mtd->writesize);
/* Read oob bytes */
- chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
- chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
+ chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
/* Calculate ecc bytes */
chip->ecc.calculate(mtd, buf, ecc_calc);
^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 12:52 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 12:52 UTC (permalink / raw)
To: Boris Brezillon, Tony Lindgren
Cc: javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 18/04/16 15:31, Roger Quadros wrote:
> On 16/04/16 11:57, Boris Brezillon wrote:
>> On Fri, 15 Apr 2016 09:19:51 -0700
>> Tony Lindgren <tony@atomide.com> wrote:
>>
>>>
>>>> Or should I just pull this immutable branch in my current nand/next and
>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>> prevent conflicts when our branches are merged into linux-next, no
>>>> matter the order.
>>>
>>> Ideally just one or more branches with just minimal changes in
>>> them against -rc1. But you may have other dependencies in
>>> your NAND tree so that may no longer be doable :) Usually if
>>> I merge something that may need to get merged into other
>>> branches, I just apply them into a separate branch against -rc1
>>> to start with, then merge that branch in.
>>
>> Okay, in this case, that's pretty much what I did from the beginning,
>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>> Thanks for this detailed explanation, I'll try to remember that when
>> I'll need to provide an immutable branch for another subsystem.
>>
>> Roger, my request remains, could you check/test my conflict resolution
>> (branch nand/next-with-gpmc-rework)?
>
> I couldn't test that branch yet as nand/next is broken on omap platforms
> (at least on dra7-evm).
>
> The commit where it breaks is:
> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>
> I'm trying to figure out what went wrong there. Failure log below.
OK. I was able to fix it when at commit a662ef4 with the below patch.
Looks like we need to read exactly the ECC bytes through the ECC engine and not
the entire OOB region.
--cheers,
-oger
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index e622a1b..46b61d2 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
chip->read_buf(mtd, buf, mtd->writesize);
/* Read oob bytes */
- chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
- chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
+ chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
/* Calculate ecc bytes */
chip->ecc.calculate(mtd, buf, ecc_calc);
^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 13:13 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-18 13:13 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Hi Roger,
On Mon, 18 Apr 2016 15:52:58 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 18/04/16 15:31, Roger Quadros wrote:
> > On 16/04/16 11:57, Boris Brezillon wrote:
> >> On Fri, 15 Apr 2016 09:19:51 -0700
> >> Tony Lindgren <tony@atomide.com> wrote:
> >>
> >>>
> >>>> Or should I just pull this immutable branch in my current nand/next and
> >>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>> prevent conflicts when our branches are merged into linux-next, no
> >>>> matter the order.
> >>>
> >>> Ideally just one or more branches with just minimal changes in
> >>> them against -rc1. But you may have other dependencies in
> >>> your NAND tree so that may no longer be doable :) Usually if
> >>> I merge something that may need to get merged into other
> >>> branches, I just apply them into a separate branch against -rc1
> >>> to start with, then merge that branch in.
> >>
> >> Okay, in this case, that's pretty much what I did from the beginning,
> >> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >> Thanks for this detailed explanation, I'll try to remember that when
> >> I'll need to provide an immutable branch for another subsystem.
> >>
> >> Roger, my request remains, could you check/test my conflict resolution
> >> (branch nand/next-with-gpmc-rework)?
> >
> > I couldn't test that branch yet as nand/next is broken on omap platforms
> > (at least on dra7-evm).
> >
> > The commit where it breaks is:
> > a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >
> > I'm trying to figure out what went wrong there. Failure log below.
>
> OK. I was able to fix it when at commit a662ef4 with the below patch.
Thanks for debugging that.
>
> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> the entire OOB region.
Hm, it looks like there's a bug somewhere else, because I don't see any
reason why the controller wouldn't be able to read the full OOB region.
>
> --cheers,
> -oger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index e622a1b..46b61d2 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> chip->read_buf(mtd, buf, mtd->writesize);
>
> /* Read oob bytes */
> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
The whole point of this series is to get rid of chip->ecc.layout, so
we'd rather use the mtd_ooblayout_find_eccregion() instead of
chip->ecc.layout->eccpos[0].
> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
Can you print the ->oobsize, ->writesize, chip->ecc.layout->eccpos[0]
and chip->ecc.total values here. I'll also need your NAND page layout
(page size and OOB size provided in the datasheet).
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 13:13 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-18 13:13 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi Roger,
On Mon, 18 Apr 2016 15:52:58 +0300
Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> On 18/04/16 15:31, Roger Quadros wrote:
> > On 16/04/16 11:57, Boris Brezillon wrote:
> >> On Fri, 15 Apr 2016 09:19:51 -0700
> >> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> >>
> >>>
> >>>> Or should I just pull this immutable branch in my current nand/next and
> >>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>> prevent conflicts when our branches are merged into linux-next, no
> >>>> matter the order.
> >>>
> >>> Ideally just one or more branches with just minimal changes in
> >>> them against -rc1. But you may have other dependencies in
> >>> your NAND tree so that may no longer be doable :) Usually if
> >>> I merge something that may need to get merged into other
> >>> branches, I just apply them into a separate branch against -rc1
> >>> to start with, then merge that branch in.
> >>
> >> Okay, in this case, that's pretty much what I did from the beginning,
> >> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >> Thanks for this detailed explanation, I'll try to remember that when
> >> I'll need to provide an immutable branch for another subsystem.
> >>
> >> Roger, my request remains, could you check/test my conflict resolution
> >> (branch nand/next-with-gpmc-rework)?
> >
> > I couldn't test that branch yet as nand/next is broken on omap platforms
> > (at least on dra7-evm).
> >
> > The commit where it breaks is:
> > a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >
> > I'm trying to figure out what went wrong there. Failure log below.
>
> OK. I was able to fix it when at commit a662ef4 with the below patch.
Thanks for debugging that.
>
> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> the entire OOB region.
Hm, it looks like there's a bug somewhere else, because I don't see any
reason why the controller wouldn't be able to read the full OOB region.
>
> --cheers,
> -oger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index e622a1b..46b61d2 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> chip->read_buf(mtd, buf, mtd->writesize);
>
> /* Read oob bytes */
> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
The whole point of this series is to get rid of chip->ecc.layout, so
we'd rather use the mtd_ooblayout_find_eccregion() instead of
chip->ecc.layout->eccpos[0].
> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
Can you print the ->oobsize, ->writesize, chip->ecc.layout->eccpos[0]
and chip->ecc.total values here. I'll also need your NAND page layout
(page size and OOB size provided in the datasheet).
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-18 13:13 ` Boris Brezillon
@ 2016-04-18 13:48 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 13:48 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Boris,
On 18/04/16 16:13, Boris Brezillon wrote:
> Hi Roger,
>
> On Mon, 18 Apr 2016 15:52:58 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> On 18/04/16 15:31, Roger Quadros wrote:
>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>
>>>>>
>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>> matter the order.
>>>>>
>>>>> Ideally just one or more branches with just minimal changes in
>>>>> them against -rc1. But you may have other dependencies in
>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>> I merge something that may need to get merged into other
>>>>> branches, I just apply them into a separate branch against -rc1
>>>>> to start with, then merge that branch in.
>>>>
>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>> I'll need to provide an immutable branch for another subsystem.
>>>>
>>>> Roger, my request remains, could you check/test my conflict resolution
>>>> (branch nand/next-with-gpmc-rework)?
>>>
>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>> (at least on dra7-evm).
>>>
>>> The commit where it breaks is:
>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>
>>> I'm trying to figure out what went wrong there. Failure log below.
>>
>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>
> Thanks for debugging that.
>
>>
>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>> the entire OOB region.
>
> Hm, it looks like there's a bug somewhere else, because I don't see any
> reason why the controller wouldn't be able to read the full OOB region.
The controller can read the full OOB region but we only want it to read just
the ECC bytes because that is the way the ELM ECC engine works.
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index e622a1b..46b61d2 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>> chip->read_buf(mtd, buf, mtd->writesize);
>>
>> /* Read oob bytes */
>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>
> The whole point of this series is to get rid of chip->ecc.layout, so
> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> chip->ecc.layout->eccpos[0].
We just need the position of the first ECC byte offset.
Is that the most optimal way to get it?
>
>> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>
> Can you print the ->oobsize, ->writesize, chip->ecc.layout->eccpos[0]
> and chip->ecc.total values here. I'll also need your NAND page layout
> (page size and OOB size provided in the datasheet).
eccpos[0]: 2, oobsize 64, ecctotal 56, writesize 2048
Nand part is MT29F2G16ABAEAWP
This has page size 2048 bytes and OOB size 64 bytes.
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 13:48 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 13:48 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Boris,
On 18/04/16 16:13, Boris Brezillon wrote:
> Hi Roger,
>
> On Mon, 18 Apr 2016 15:52:58 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> On 18/04/16 15:31, Roger Quadros wrote:
>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>
>>>>>
>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>> matter the order.
>>>>>
>>>>> Ideally just one or more branches with just minimal changes in
>>>>> them against -rc1. But you may have other dependencies in
>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>> I merge something that may need to get merged into other
>>>>> branches, I just apply them into a separate branch against -rc1
>>>>> to start with, then merge that branch in.
>>>>
>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>> I'll need to provide an immutable branch for another subsystem.
>>>>
>>>> Roger, my request remains, could you check/test my conflict resolution
>>>> (branch nand/next-with-gpmc-rework)?
>>>
>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>> (at least on dra7-evm).
>>>
>>> The commit where it breaks is:
>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>
>>> I'm trying to figure out what went wrong there. Failure log below.
>>
>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>
> Thanks for debugging that.
>
>>
>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>> the entire OOB region.
>
> Hm, it looks like there's a bug somewhere else, because I don't see any
> reason why the controller wouldn't be able to read the full OOB region.
The controller can read the full OOB region but we only want it to read just
the ECC bytes because that is the way the ELM ECC engine works.
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index e622a1b..46b61d2 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>> chip->read_buf(mtd, buf, mtd->writesize);
>>
>> /* Read oob bytes */
>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>
> The whole point of this series is to get rid of chip->ecc.layout, so
> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> chip->ecc.layout->eccpos[0].
We just need the position of the first ECC byte offset.
Is that the most optimal way to get it?
>
>> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>
> Can you print the ->oobsize, ->writesize, chip->ecc.layout->eccpos[0]
> and chip->ecc.total values here. I'll also need your NAND page layout
> (page size and OOB size provided in the datasheet).
eccpos[0]: 2, oobsize 64, ecctotal 56, writesize 2048
Nand part is MT29F2G16ABAEAWP
This has page size 2048 bytes and OOB size 64 bytes.
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 14:10 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-18 14:10 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Mon, 18 Apr 2016 16:48:26 +0300
Roger Quadros <rogerq@ti.com> wrote:
> Boris,
>
> On 18/04/16 16:13, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Mon, 18 Apr 2016 15:52:58 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> On 18/04/16 15:31, Roger Quadros wrote:
> >>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>> Tony Lindgren <tony@atomide.com> wrote:
> >>>>
> >>>>>
> >>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>> matter the order.
> >>>>>
> >>>>> Ideally just one or more branches with just minimal changes in
> >>>>> them against -rc1. But you may have other dependencies in
> >>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>> I merge something that may need to get merged into other
> >>>>> branches, I just apply them into a separate branch against -rc1
> >>>>> to start with, then merge that branch in.
> >>>>
> >>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>> I'll need to provide an immutable branch for another subsystem.
> >>>>
> >>>> Roger, my request remains, could you check/test my conflict resolution
> >>>> (branch nand/next-with-gpmc-rework)?
> >>>
> >>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>> (at least on dra7-evm).
> >>>
> >>> The commit where it breaks is:
> >>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>
> >>> I'm trying to figure out what went wrong there. Failure log below.
> >>
> >> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >
> > Thanks for debugging that.
> >
> >>
> >> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >> the entire OOB region.
> >
> > Hm, it looks like there's a bug somewhere else, because I don't see any
> > reason why the controller wouldn't be able to read the full OOB region.
>
> The controller can read the full OOB region but we only want it to read just
> the ECC bytes because that is the way the ELM ECC engine works.
Ok, I think I got it: the ECC correction is pipelined with data read,
and the controller expect to have ECC bytes right after the in-band
data, is that correct?
>
> >>
> >> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >> index e622a1b..46b61d2 100644
> >> --- a/drivers/mtd/nand/omap2.c
> >> +++ b/drivers/mtd/nand/omap2.c
> >> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >> chip->read_buf(mtd, buf, mtd->writesize);
> >>
> >> /* Read oob bytes */
> >> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >
> > The whole point of this series is to get rid of chip->ecc.layout, so
> > we'd rather use the mtd_ooblayout_find_eccregion() instead of
> > chip->ecc.layout->eccpos[0].
>
> We just need the position of the first ECC byte offset.
> Is that the most optimal way to get it?
For the BCH case, it seems that ECC bytes always start at offset
BADBLOCK_MARKER_LENGTH, so you can just pass
mtd->writesize + BADBLOCK_MARKER_LENGTH.
Let me know if this works, and I'll squash those changes into the
faulty commit (I know this implies a rebase + push -f, but IMO that's
better than breaking bisectability).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 14:10 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-18 14:10 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Mon, 18 Apr 2016 16:48:26 +0300
Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> Boris,
>
> On 18/04/16 16:13, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Mon, 18 Apr 2016 15:52:58 +0300
> > Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> >
> >> On 18/04/16 15:31, Roger Quadros wrote:
> >>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> >>>>
> >>>>>
> >>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>> matter the order.
> >>>>>
> >>>>> Ideally just one or more branches with just minimal changes in
> >>>>> them against -rc1. But you may have other dependencies in
> >>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>> I merge something that may need to get merged into other
> >>>>> branches, I just apply them into a separate branch against -rc1
> >>>>> to start with, then merge that branch in.
> >>>>
> >>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>> I'll need to provide an immutable branch for another subsystem.
> >>>>
> >>>> Roger, my request remains, could you check/test my conflict resolution
> >>>> (branch nand/next-with-gpmc-rework)?
> >>>
> >>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>> (at least on dra7-evm).
> >>>
> >>> The commit where it breaks is:
> >>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>
> >>> I'm trying to figure out what went wrong there. Failure log below.
> >>
> >> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >
> > Thanks for debugging that.
> >
> >>
> >> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >> the entire OOB region.
> >
> > Hm, it looks like there's a bug somewhere else, because I don't see any
> > reason why the controller wouldn't be able to read the full OOB region.
>
> The controller can read the full OOB region but we only want it to read just
> the ECC bytes because that is the way the ELM ECC engine works.
Ok, I think I got it: the ECC correction is pipelined with data read,
and the controller expect to have ECC bytes right after the in-band
data, is that correct?
>
> >>
> >> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >> index e622a1b..46b61d2 100644
> >> --- a/drivers/mtd/nand/omap2.c
> >> +++ b/drivers/mtd/nand/omap2.c
> >> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >> chip->read_buf(mtd, buf, mtd->writesize);
> >>
> >> /* Read oob bytes */
> >> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >
> > The whole point of this series is to get rid of chip->ecc.layout, so
> > we'd rather use the mtd_ooblayout_find_eccregion() instead of
> > chip->ecc.layout->eccpos[0].
>
> We just need the position of the first ECC byte offset.
> Is that the most optimal way to get it?
For the BCH case, it seems that ECC bytes always start at offset
BADBLOCK_MARKER_LENGTH, so you can just pass
mtd->writesize + BADBLOCK_MARKER_LENGTH.
Let me know if this works, and I'll squash those changes into the
faulty commit (I know this implies a rebase + push -f, but IMO that's
better than breaking bisectability).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-18 14:10 ` Boris Brezillon
@ 2016-04-18 14:39 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 14:39 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 18/04/16 17:10, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 16:48:26 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> Boris,
>>
>> On 18/04/16 16:13, Boris Brezillon wrote:
>>> Hi Roger,
>>>
>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>> Roger Quadros <rogerq@ti.com> wrote:
>>>
>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>> matter the order.
>>>>>>>
>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>> I merge something that may need to get merged into other
>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>> to start with, then merge that branch in.
>>>>>>
>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>
>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>
>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>> (at least on dra7-evm).
>>>>>
>>>>> The commit where it breaks is:
>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>
>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>
>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>
>>> Thanks for debugging that.
>>>
>>>>
>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>> the entire OOB region.
>>>
>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>> reason why the controller wouldn't be able to read the full OOB region.
>>
>> The controller can read the full OOB region but we only want it to read just
>> the ECC bytes because that is the way the ELM ECC engine works.
>
> Ok, I think I got it: the ECC correction is pipelined with data read,
> and the controller expect to have ECC bytes right after the in-band
> data, is that correct?
That is correct.
>
>>
>>>>
>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>> index e622a1b..46b61d2 100644
>>>> --- a/drivers/mtd/nand/omap2.c
>>>> +++ b/drivers/mtd/nand/omap2.c
>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>
>>>> /* Read oob bytes */
>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>
>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>> chip->ecc.layout->eccpos[0].
>>
>> We just need the position of the first ECC byte offset.
>> Is that the most optimal way to get it?
>
> For the BCH case, it seems that ECC bytes always start at offset
> BADBLOCK_MARKER_LENGTH, so you can just pass
> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>
> Let me know if this works, and I'll squash those changes into the
> faulty commit (I know this implies a rebase + push -f, but IMO that's
> better than breaking bisectability).
>
>
So, the below patch works as well. Please feel free to fold it with your patch.
--
cheers,
-roger
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index e622a1b..eb85d6b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
chip->read_buf(mtd, buf, mtd->writesize);
/* Read oob bytes */
- chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
- chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
+ chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
/* Calculate ecc bytes */
chip->ecc.calculate(mtd, buf, ecc_calc);
^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 14:39 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-18 14:39 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 18/04/16 17:10, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 16:48:26 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> Boris,
>>
>> On 18/04/16 16:13, Boris Brezillon wrote:
>>> Hi Roger,
>>>
>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>> Roger Quadros <rogerq@ti.com> wrote:
>>>
>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>> matter the order.
>>>>>>>
>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>> I merge something that may need to get merged into other
>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>> to start with, then merge that branch in.
>>>>>>
>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>
>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>
>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>> (at least on dra7-evm).
>>>>>
>>>>> The commit where it breaks is:
>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>
>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>
>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>
>>> Thanks for debugging that.
>>>
>>>>
>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>> the entire OOB region.
>>>
>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>> reason why the controller wouldn't be able to read the full OOB region.
>>
>> The controller can read the full OOB region but we only want it to read just
>> the ECC bytes because that is the way the ELM ECC engine works.
>
> Ok, I think I got it: the ECC correction is pipelined with data read,
> and the controller expect to have ECC bytes right after the in-band
> data, is that correct?
That is correct.
>
>>
>>>>
>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>> index e622a1b..46b61d2 100644
>>>> --- a/drivers/mtd/nand/omap2.c
>>>> +++ b/drivers/mtd/nand/omap2.c
>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>
>>>> /* Read oob bytes */
>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>
>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>> chip->ecc.layout->eccpos[0].
>>
>> We just need the position of the first ECC byte offset.
>> Is that the most optimal way to get it?
>
> For the BCH case, it seems that ECC bytes always start at offset
> BADBLOCK_MARKER_LENGTH, so you can just pass
> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>
> Let me know if this works, and I'll squash those changes into the
> faulty commit (I know this implies a rebase + push -f, but IMO that's
> better than breaking bisectability).
>
>
So, the below patch works as well. Please feel free to fold it with your patch.
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-18 14:39 ` Roger Quadros
@ 2016-04-18 14:57 ` Boris Brezillon
-1 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-18 14:57 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Mon, 18 Apr 2016 17:39:01 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 18/04/16 17:10, Boris Brezillon wrote:
> > On Mon, 18 Apr 2016 16:48:26 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Boris,
> >>
> >> On 18/04/16 16:13, Boris Brezillon wrote:
> >>> Hi Roger,
> >>>
> >>> On Mon, 18 Apr 2016 15:52:58 +0300
> >>> Roger Quadros <rogerq@ti.com> wrote:
> >>>
> >>>> On 18/04/16 15:31, Roger Quadros wrote:
> >>>>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>>>> Tony Lindgren <tony@atomide.com> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>>>> matter the order.
> >>>>>>>
> >>>>>>> Ideally just one or more branches with just minimal changes in
> >>>>>>> them against -rc1. But you may have other dependencies in
> >>>>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>>>> I merge something that may need to get merged into other
> >>>>>>> branches, I just apply them into a separate branch against -rc1
> >>>>>>> to start with, then merge that branch in.
> >>>>>>
> >>>>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>>>> I'll need to provide an immutable branch for another subsystem.
> >>>>>>
> >>>>>> Roger, my request remains, could you check/test my conflict resolution
> >>>>>> (branch nand/next-with-gpmc-rework)?
> >>>>>
> >>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>>>> (at least on dra7-evm).
> >>>>>
> >>>>> The commit where it breaks is:
> >>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>>>
> >>>>> I'm trying to figure out what went wrong there. Failure log below.
> >>>>
> >>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >>>
> >>> Thanks for debugging that.
> >>>
> >>>>
> >>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >>>> the entire OOB region.
> >>>
> >>> Hm, it looks like there's a bug somewhere else, because I don't see any
> >>> reason why the controller wouldn't be able to read the full OOB region.
> >>
> >> The controller can read the full OOB region but we only want it to read just
> >> the ECC bytes because that is the way the ELM ECC engine works.
> >
> > Ok, I think I got it: the ECC correction is pipelined with data read,
> > and the controller expect to have ECC bytes right after the in-band
> > data, is that correct?
>
> That is correct.
>
> >
> >>
> >>>>
> >>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>> index e622a1b..46b61d2 100644
> >>>> --- a/drivers/mtd/nand/omap2.c
> >>>> +++ b/drivers/mtd/nand/omap2.c
> >>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >>>> chip->read_buf(mtd, buf, mtd->writesize);
> >>>>
> >>>> /* Read oob bytes */
> >>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >>>
> >>> The whole point of this series is to get rid of chip->ecc.layout, so
> >>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> >>> chip->ecc.layout->eccpos[0].
> >>
> >> We just need the position of the first ECC byte offset.
> >> Is that the most optimal way to get it?
> >
> > For the BCH case, it seems that ECC bytes always start at offset
> > BADBLOCK_MARKER_LENGTH, so you can just pass
> > mtd->writesize + BADBLOCK_MARKER_LENGTH.
> >
> > Let me know if this works, and I'll squash those changes into the
> > faulty commit (I know this implies a rebase + push -f, but IMO that's
> > better than breaking bisectability).
> >
> >
>
> So, the below patch works as well. Please feel free to fold it with your patch.
Will do.
Thanks,
Boris
>
> --
> cheers,
> -roger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index e622a1b..eb85d6b 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> chip->read_buf(mtd, buf, mtd->writesize);
>
> /* Read oob bytes */
> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>
> /* Calculate ecc bytes */
> chip->ecc.calculate(mtd, buf, ecc_calc);
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-18 14:57 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-18 14:57 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Mon, 18 Apr 2016 17:39:01 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 18/04/16 17:10, Boris Brezillon wrote:
> > On Mon, 18 Apr 2016 16:48:26 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Boris,
> >>
> >> On 18/04/16 16:13, Boris Brezillon wrote:
> >>> Hi Roger,
> >>>
> >>> On Mon, 18 Apr 2016 15:52:58 +0300
> >>> Roger Quadros <rogerq@ti.com> wrote:
> >>>
> >>>> On 18/04/16 15:31, Roger Quadros wrote:
> >>>>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>>>> Tony Lindgren <tony@atomide.com> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>>>> matter the order.
> >>>>>>>
> >>>>>>> Ideally just one or more branches with just minimal changes in
> >>>>>>> them against -rc1. But you may have other dependencies in
> >>>>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>>>> I merge something that may need to get merged into other
> >>>>>>> branches, I just apply them into a separate branch against -rc1
> >>>>>>> to start with, then merge that branch in.
> >>>>>>
> >>>>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>>>> I'll need to provide an immutable branch for another subsystem.
> >>>>>>
> >>>>>> Roger, my request remains, could you check/test my conflict resolution
> >>>>>> (branch nand/next-with-gpmc-rework)?
> >>>>>
> >>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>>>> (at least on dra7-evm).
> >>>>>
> >>>>> The commit where it breaks is:
> >>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>>>
> >>>>> I'm trying to figure out what went wrong there. Failure log below.
> >>>>
> >>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >>>
> >>> Thanks for debugging that.
> >>>
> >>>>
> >>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >>>> the entire OOB region.
> >>>
> >>> Hm, it looks like there's a bug somewhere else, because I don't see any
> >>> reason why the controller wouldn't be able to read the full OOB region.
> >>
> >> The controller can read the full OOB region but we only want it to read just
> >> the ECC bytes because that is the way the ELM ECC engine works.
> >
> > Ok, I think I got it: the ECC correction is pipelined with data read,
> > and the controller expect to have ECC bytes right after the in-band
> > data, is that correct?
>
> That is correct.
>
> >
> >>
> >>>>
> >>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>> index e622a1b..46b61d2 100644
> >>>> --- a/drivers/mtd/nand/omap2.c
> >>>> +++ b/drivers/mtd/nand/omap2.c
> >>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >>>> chip->read_buf(mtd, buf, mtd->writesize);
> >>>>
> >>>> /* Read oob bytes */
> >>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >>>
> >>> The whole point of this series is to get rid of chip->ecc.layout, so
> >>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> >>> chip->ecc.layout->eccpos[0].
> >>
> >> We just need the position of the first ECC byte offset.
> >> Is that the most optimal way to get it?
> >
> > For the BCH case, it seems that ECC bytes always start at offset
> > BADBLOCK_MARKER_LENGTH, so you can just pass
> > mtd->writesize + BADBLOCK_MARKER_LENGTH.
> >
> > Let me know if this works, and I'll squash those changes into the
> > faulty commit (I know this implies a rebase + push -f, but IMO that's
> > better than breaking bisectability).
> >
> >
>
> So, the below patch works as well. Please feel free to fold it with your patch.
Will do.
Thanks,
Boris
>
> --
> cheers,
> -roger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index e622a1b..eb85d6b 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> chip->read_buf(mtd, buf, mtd->writesize);
>
> /* Read oob bytes */
> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>
> /* Calculate ecc bytes */
> chip->ecc.calculate(mtd, buf, ecc_calc);
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-18 14:57 ` Boris Brezillon
@ 2016-04-19 12:46 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-19 12:46 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Boris,
On 18/04/16 17:57, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 17:39:01 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> On 18/04/16 17:10, Boris Brezillon wrote:
>>> On Mon, 18 Apr 2016 16:48:26 +0300
>>> Roger Quadros <rogerq@ti.com> wrote:
>>>
>>>> Boris,
>>>>
>>>> On 18/04/16 16:13, Boris Brezillon wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>>>> Roger Quadros <rogerq@ti.com> wrote:
>>>>>
>>>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>>>> matter the order.
>>>>>>>>>
>>>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>>>> I merge something that may need to get merged into other
>>>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>>>> to start with, then merge that branch in.
>>>>>>>>
>>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>>>
>>>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>>>
>>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>>>> (at least on dra7-evm).
>>>>>>>
>>>>>>> The commit where it breaks is:
>>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>>>
>>>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>>>
>>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>>>
>>>>> Thanks for debugging that.
>>>>>
>>>>>>
>>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>>>> the entire OOB region.
>>>>>
>>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>>>> reason why the controller wouldn't be able to read the full OOB region.
>>>>
>>>> The controller can read the full OOB region but we only want it to read just
>>>> the ECC bytes because that is the way the ELM ECC engine works.
>>>
>>> Ok, I think I got it: the ECC correction is pipelined with data read,
>>> and the controller expect to have ECC bytes right after the in-band
>>> data, is that correct?
>>
>> That is correct.
>>
>>>
>>>>
>>>>>>
>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>> index e622a1b..46b61d2 100644
>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>>>
>>>>>> /* Read oob bytes */
>>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>>>
>>>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>>>> chip->ecc.layout->eccpos[0].
>>>>
>>>> We just need the position of the first ECC byte offset.
>>>> Is that the most optimal way to get it?
>>>
>>> For the BCH case, it seems that ECC bytes always start at offset
>>> BADBLOCK_MARKER_LENGTH, so you can just pass
>>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>>>
>>> Let me know if this works, and I'll squash those changes into the
>>> faulty commit (I know this implies a rebase + push -f, but IMO that's
>>> better than breaking bisectability).
>>>
>>>
>>
>> So, the below patch works as well. Please feel free to fold it with your patch.
>
> Will do.
>
> Thanks,
>
> Boris
After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
and it worked fine.
[1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
I'd be happy to test the branch again after you've incorporated all changes.
Since you are gong to do a push -f anyways, I was wondering if you want to pull in my
gpmc branch first to avoid the merge conflict. But it is totally up to you.
--
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-19 12:46 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-19 12:46 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
Boris,
On 18/04/16 17:57, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 17:39:01 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> On 18/04/16 17:10, Boris Brezillon wrote:
>>> On Mon, 18 Apr 2016 16:48:26 +0300
>>> Roger Quadros <rogerq@ti.com> wrote:
>>>
>>>> Boris,
>>>>
>>>> On 18/04/16 16:13, Boris Brezillon wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>>>> Roger Quadros <rogerq@ti.com> wrote:
>>>>>
>>>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>>>> matter the order.
>>>>>>>>>
>>>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>>>> I merge something that may need to get merged into other
>>>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>>>> to start with, then merge that branch in.
>>>>>>>>
>>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>>>
>>>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>>>
>>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>>>> (at least on dra7-evm).
>>>>>>>
>>>>>>> The commit where it breaks is:
>>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>>>
>>>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>>>
>>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>>>
>>>>> Thanks for debugging that.
>>>>>
>>>>>>
>>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>>>> the entire OOB region.
>>>>>
>>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>>>> reason why the controller wouldn't be able to read the full OOB region.
>>>>
>>>> The controller can read the full OOB region but we only want it to read just
>>>> the ECC bytes because that is the way the ELM ECC engine works.
>>>
>>> Ok, I think I got it: the ECC correction is pipelined with data read,
>>> and the controller expect to have ECC bytes right after the in-band
>>> data, is that correct?
>>
>> That is correct.
>>
>>>
>>>>
>>>>>>
>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>> index e622a1b..46b61d2 100644
>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>>>
>>>>>> /* Read oob bytes */
>>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>>>
>>>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>>>> chip->ecc.layout->eccpos[0].
>>>>
>>>> We just need the position of the first ECC byte offset.
>>>> Is that the most optimal way to get it?
>>>
>>> For the BCH case, it seems that ECC bytes always start at offset
>>> BADBLOCK_MARKER_LENGTH, so you can just pass
>>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>>>
>>> Let me know if this works, and I'll squash those changes into the
>>> faulty commit (I know this implies a rebase + push -f, but IMO that's
>>> better than breaking bisectability).
>>>
>>>
>>
>> So, the below patch works as well. Please feel free to fold it with your patch.
>
> Will do.
>
> Thanks,
>
> Boris
After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
and it worked fine.
[1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
I'd be happy to test the branch again after you've incorporated all changes.
Since you are gong to do a push -f anyways, I was wondering if you want to pull in my
gpmc branch first to avoid the merge conflict. But it is totally up to you.
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-19 12:46 ` Roger Quadros
@ 2016-04-19 12:50 ` Boris Brezillon
-1 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-19 12:50 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Tue, 19 Apr 2016 15:46:19 +0300
Roger Quadros <rogerq@ti.com> wrote:
> Boris,
>
> On 18/04/16 17:57, Boris Brezillon wrote:
> > On Mon, 18 Apr 2016 17:39:01 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> On 18/04/16 17:10, Boris Brezillon wrote:
> >>> On Mon, 18 Apr 2016 16:48:26 +0300
> >>> Roger Quadros <rogerq@ti.com> wrote:
> >>>
> >>>> Boris,
> >>>>
> >>>> On 18/04/16 16:13, Boris Brezillon wrote:
> >>>>> Hi Roger,
> >>>>>
> >>>>> On Mon, 18 Apr 2016 15:52:58 +0300
> >>>>> Roger Quadros <rogerq@ti.com> wrote:
> >>>>>
> >>>>>> On 18/04/16 15:31, Roger Quadros wrote:
> >>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>>>>>> Tony Lindgren <tony@atomide.com> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>>>>>> matter the order.
> >>>>>>>>>
> >>>>>>>>> Ideally just one or more branches with just minimal changes in
> >>>>>>>>> them against -rc1. But you may have other dependencies in
> >>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>>>>>> I merge something that may need to get merged into other
> >>>>>>>>> branches, I just apply them into a separate branch against -rc1
> >>>>>>>>> to start with, then merge that branch in.
> >>>>>>>>
> >>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>>>>>> I'll need to provide an immutable branch for another subsystem.
> >>>>>>>>
> >>>>>>>> Roger, my request remains, could you check/test my conflict resolution
> >>>>>>>> (branch nand/next-with-gpmc-rework)?
> >>>>>>>
> >>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>>>>>> (at least on dra7-evm).
> >>>>>>>
> >>>>>>> The commit where it breaks is:
> >>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>>>>>
> >>>>>>> I'm trying to figure out what went wrong there. Failure log below.
> >>>>>>
> >>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >>>>>
> >>>>> Thanks for debugging that.
> >>>>>
> >>>>>>
> >>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >>>>>> the entire OOB region.
> >>>>>
> >>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
> >>>>> reason why the controller wouldn't be able to read the full OOB region.
> >>>>
> >>>> The controller can read the full OOB region but we only want it to read just
> >>>> the ECC bytes because that is the way the ELM ECC engine works.
> >>>
> >>> Ok, I think I got it: the ECC correction is pipelined with data read,
> >>> and the controller expect to have ECC bytes right after the in-band
> >>> data, is that correct?
> >>
> >> That is correct.
> >>
> >>>
> >>>>
> >>>>>>
> >>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>>>> index e622a1b..46b61d2 100644
> >>>>>> --- a/drivers/mtd/nand/omap2.c
> >>>>>> +++ b/drivers/mtd/nand/omap2.c
> >>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >>>>>> chip->read_buf(mtd, buf, mtd->writesize);
> >>>>>>
> >>>>>> /* Read oob bytes */
> >>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >>>>>
> >>>>> The whole point of this series is to get rid of chip->ecc.layout, so
> >>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> >>>>> chip->ecc.layout->eccpos[0].
> >>>>
> >>>> We just need the position of the first ECC byte offset.
> >>>> Is that the most optimal way to get it?
> >>>
> >>> For the BCH case, it seems that ECC bytes always start at offset
> >>> BADBLOCK_MARKER_LENGTH, so you can just pass
> >>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
> >>>
> >>> Let me know if this works, and I'll squash those changes into the
> >>> faulty commit (I know this implies a rebase + push -f, but IMO that's
> >>> better than breaking bisectability).
> >>>
> >>>
> >>
> >> So, the below patch works as well. Please feel free to fold it with your patch.
> >
> > Will do.
> >
> > Thanks,
> >
> > Boris
>
> After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
> and it worked fine.
>
> [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
>
> I'd be happy to test the branch again after you've incorporated all changes.
>
> Since you are gong to do a push -f anyways, I was wondering if you want to pull in my
> gpmc branch first to avoid the merge conflict. But it is totally up to you.
Sure, I can do that.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-19 12:50 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-19 12:50 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Tue, 19 Apr 2016 15:46:19 +0300
Roger Quadros <rogerq@ti.com> wrote:
> Boris,
>
> On 18/04/16 17:57, Boris Brezillon wrote:
> > On Mon, 18 Apr 2016 17:39:01 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> On 18/04/16 17:10, Boris Brezillon wrote:
> >>> On Mon, 18 Apr 2016 16:48:26 +0300
> >>> Roger Quadros <rogerq@ti.com> wrote:
> >>>
> >>>> Boris,
> >>>>
> >>>> On 18/04/16 16:13, Boris Brezillon wrote:
> >>>>> Hi Roger,
> >>>>>
> >>>>> On Mon, 18 Apr 2016 15:52:58 +0300
> >>>>> Roger Quadros <rogerq@ti.com> wrote:
> >>>>>
> >>>>>> On 18/04/16 15:31, Roger Quadros wrote:
> >>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>>>>>> Tony Lindgren <tony@atomide.com> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>>>>>> matter the order.
> >>>>>>>>>
> >>>>>>>>> Ideally just one or more branches with just minimal changes in
> >>>>>>>>> them against -rc1. But you may have other dependencies in
> >>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>>>>>> I merge something that may need to get merged into other
> >>>>>>>>> branches, I just apply them into a separate branch against -rc1
> >>>>>>>>> to start with, then merge that branch in.
> >>>>>>>>
> >>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>>>>>> I'll need to provide an immutable branch for another subsystem.
> >>>>>>>>
> >>>>>>>> Roger, my request remains, could you check/test my conflict resolution
> >>>>>>>> (branch nand/next-with-gpmc-rework)?
> >>>>>>>
> >>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>>>>>> (at least on dra7-evm).
> >>>>>>>
> >>>>>>> The commit where it breaks is:
> >>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>>>>>
> >>>>>>> I'm trying to figure out what went wrong there. Failure log below.
> >>>>>>
> >>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >>>>>
> >>>>> Thanks for debugging that.
> >>>>>
> >>>>>>
> >>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >>>>>> the entire OOB region.
> >>>>>
> >>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
> >>>>> reason why the controller wouldn't be able to read the full OOB region.
> >>>>
> >>>> The controller can read the full OOB region but we only want it to read just
> >>>> the ECC bytes because that is the way the ELM ECC engine works.
> >>>
> >>> Ok, I think I got it: the ECC correction is pipelined with data read,
> >>> and the controller expect to have ECC bytes right after the in-band
> >>> data, is that correct?
> >>
> >> That is correct.
> >>
> >>>
> >>>>
> >>>>>>
> >>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>>>> index e622a1b..46b61d2 100644
> >>>>>> --- a/drivers/mtd/nand/omap2.c
> >>>>>> +++ b/drivers/mtd/nand/omap2.c
> >>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >>>>>> chip->read_buf(mtd, buf, mtd->writesize);
> >>>>>>
> >>>>>> /* Read oob bytes */
> >>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >>>>>
> >>>>> The whole point of this series is to get rid of chip->ecc.layout, so
> >>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> >>>>> chip->ecc.layout->eccpos[0].
> >>>>
> >>>> We just need the position of the first ECC byte offset.
> >>>> Is that the most optimal way to get it?
> >>>
> >>> For the BCH case, it seems that ECC bytes always start at offset
> >>> BADBLOCK_MARKER_LENGTH, so you can just pass
> >>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
> >>>
> >>> Let me know if this works, and I'll squash those changes into the
> >>> faulty commit (I know this implies a rebase + push -f, but IMO that's
> >>> better than breaking bisectability).
> >>>
> >>>
> >>
> >> So, the below patch works as well. Please feel free to fold it with your patch.
> >
> > Will do.
> >
> > Thanks,
> >
> > Boris
>
> After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
> and it worked fine.
>
> [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
>
> I'd be happy to test the branch again after you've incorporated all changes.
>
> Since you are gong to do a push -f anyways, I was wondering if you want to pull in my
> gpmc branch first to avoid the merge conflict. But it is totally up to you.
Sure, I can do that.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-19 12:46 ` Roger Quadros
@ 2016-04-19 20:11 ` Boris Brezillon
-1 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-19 20:11 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Tue, 19 Apr 2016 15:46:19 +0300
Roger Quadros <rogerq@ti.com> wrote:
>
> After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
> and it worked fine.
>
> [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
>
> I'd be happy to test the branch again after you've incorporated all changes.
Just pushed what's supposed to be my new nand/next into
nand/next-with-gpmc-rework, can you test it? I'll push it to nand/next
once I have your confirmation that everything is good.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-19 20:11 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-19 20:11 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Tue, 19 Apr 2016 15:46:19 +0300
Roger Quadros <rogerq@ti.com> wrote:
>
> After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
> and it worked fine.
>
> [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
>
> I'd be happy to test the branch again after you've incorporated all changes.
Just pushed what's supposed to be my new nand/next into
nand/next-with-gpmc-rework, can you test it? I'll push it to nand/next
once I have your confirmation that everything is good.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-19 20:11 ` Boris Brezillon
@ 2016-04-20 8:58 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-20 8:58 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 19/04/16 23:11, Boris Brezillon wrote:
> On Tue, 19 Apr 2016 15:46:19 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>>
>> After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
>> and it worked fine.
>>
>> [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
>>
>> I'd be happy to test the branch again after you've incorporated all changes.
>
> Just pushed what's supposed to be my new nand/next into
> nand/next-with-gpmc-rework, can you test it? I'll push it to nand/next
> once I have your confirmation that everything is good.
>
Tested this on dra7-evm, am437x-gp-evm and omap3-beagle and all seems good. Thanks :).
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-20 8:58 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-20 8:58 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 19/04/16 23:11, Boris Brezillon wrote:
> On Tue, 19 Apr 2016 15:46:19 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>>
>> After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
>> and it worked fine.
>>
>> [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
>>
>> I'd be happy to test the branch again after you've incorporated all changes.
>
> Just pushed what's supposed to be my new nand/next into
> nand/next-with-gpmc-rework, can you test it? I'll push it to nand/next
> once I have your confirmation that everything is good.
>
Tested this on dra7-evm, am437x-gp-evm and omap3-beagle and all seems good. Thanks :).
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-19 20:11 ` Boris Brezillon
@ 2016-04-20 14:45 ` Tony Lindgren
-1 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-20 14:45 UTC (permalink / raw)
To: Boris Brezillon
Cc: Roger Quadros, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
* Boris Brezillon <boris.brezillon@free-electrons.com> [160419 13:13]:
> On Tue, 19 Apr 2016 15:46:19 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
> >
> > After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
> > and it worked fine.
> >
> > [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
> >
> > I'd be happy to test the branch again after you've incorporated all changes.
>
> Just pushed what's supposed to be my new nand/next into
> nand/next-with-gpmc-rework, can you test it? I'll push it to nand/next
> once I have your confirmation that everything is good.
Looks good to me too, merges fine with my for-next and still
works for me.
Thanks,
Tony
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-20 14:45 ` Tony Lindgren
0 siblings, 0 replies; 93+ messages in thread
From: Tony Lindgren @ 2016-04-20 14:45 UTC (permalink / raw)
To: Boris Brezillon
Cc: Roger Quadros, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
* Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> [160419 13:13]:
> On Tue, 19 Apr 2016 15:46:19 +0300
> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
>
> >
> > After all the changes we discussed in [1] I was able to test nand/next-with-gpmc-rework
> > and it worked fine.
> >
> > [1] - http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/22596/focus=22936
> >
> > I'd be happy to test the branch again after you've incorporated all changes.
>
> Just pushed what's supposed to be my new nand/next into
> nand/next-with-gpmc-rework, can you test it? I'll push it to nand/next
> once I have your confirmation that everything is good.
Looks good to me too, merges fine with my for-next and still
works for me.
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-18 14:39 ` Roger Quadros
@ 2016-04-19 13:22 ` Boris Brezillon
-1 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-19 13:22 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Mon, 18 Apr 2016 17:39:01 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 18/04/16 17:10, Boris Brezillon wrote:
> > On Mon, 18 Apr 2016 16:48:26 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Boris,
> >>
> >> On 18/04/16 16:13, Boris Brezillon wrote:
> >>> Hi Roger,
> >>>
> >>> On Mon, 18 Apr 2016 15:52:58 +0300
> >>> Roger Quadros <rogerq@ti.com> wrote:
> >>>
> >>>> On 18/04/16 15:31, Roger Quadros wrote:
> >>>>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>>>> Tony Lindgren <tony@atomide.com> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>>>> matter the order.
> >>>>>>>
> >>>>>>> Ideally just one or more branches with just minimal changes in
> >>>>>>> them against -rc1. But you may have other dependencies in
> >>>>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>>>> I merge something that may need to get merged into other
> >>>>>>> branches, I just apply them into a separate branch against -rc1
> >>>>>>> to start with, then merge that branch in.
> >>>>>>
> >>>>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>>>> I'll need to provide an immutable branch for another subsystem.
> >>>>>>
> >>>>>> Roger, my request remains, could you check/test my conflict resolution
> >>>>>> (branch nand/next-with-gpmc-rework)?
> >>>>>
> >>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>>>> (at least on dra7-evm).
> >>>>>
> >>>>> The commit where it breaks is:
> >>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>>>
> >>>>> I'm trying to figure out what went wrong there. Failure log below.
> >>>>
> >>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >>>
> >>> Thanks for debugging that.
> >>>
> >>>>
> >>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >>>> the entire OOB region.
> >>>
> >>> Hm, it looks like there's a bug somewhere else, because I don't see any
> >>> reason why the controller wouldn't be able to read the full OOB region.
> >>
> >> The controller can read the full OOB region but we only want it to read just
> >> the ECC bytes because that is the way the ELM ECC engine works.
> >
> > Ok, I think I got it: the ECC correction is pipelined with data read,
> > and the controller expect to have ECC bytes right after the in-band
> > data, is that correct?
>
> That is correct.
>
> >
> >>
> >>>>
> >>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>> index e622a1b..46b61d2 100644
> >>>> --- a/drivers/mtd/nand/omap2.c
> >>>> +++ b/drivers/mtd/nand/omap2.c
> >>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >>>> chip->read_buf(mtd, buf, mtd->writesize);
> >>>>
> >>>> /* Read oob bytes */
> >>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >>>
> >>> The whole point of this series is to get rid of chip->ecc.layout, so
> >>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> >>> chip->ecc.layout->eccpos[0].
> >>
> >> We just need the position of the first ECC byte offset.
> >> Is that the most optimal way to get it?
> >
> > For the BCH case, it seems that ECC bytes always start at offset
> > BADBLOCK_MARKER_LENGTH, so you can just pass
> > mtd->writesize + BADBLOCK_MARKER_LENGTH.
> >
> > Let me know if this works, and I'll squash those changes into the
> > faulty commit (I know this implies a rebase + push -f, but IMO that's
> > better than breaking bisectability).
> >
> >
>
> So, the below patch works as well. Please feel free to fold it with your patch.
>
> --
> cheers,
> -roger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index e622a1b..eb85d6b 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> chip->read_buf(mtd, buf, mtd->writesize);
>
> /* Read oob bytes */
> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
Are you sure this patch works? Cause it seems to me that it should be
chip->read_buf(mtd, chip->oob_poi + BADBLOCK_MARKER_LENGTH,
chip->ecc.total);
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-19 13:22 ` Boris Brezillon
0 siblings, 0 replies; 93+ messages in thread
From: Boris Brezillon @ 2016-04-19 13:22 UTC (permalink / raw)
To: Roger Quadros
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On Mon, 18 Apr 2016 17:39:01 +0300
Roger Quadros <rogerq@ti.com> wrote:
> On 18/04/16 17:10, Boris Brezillon wrote:
> > On Mon, 18 Apr 2016 16:48:26 +0300
> > Roger Quadros <rogerq@ti.com> wrote:
> >
> >> Boris,
> >>
> >> On 18/04/16 16:13, Boris Brezillon wrote:
> >>> Hi Roger,
> >>>
> >>> On Mon, 18 Apr 2016 15:52:58 +0300
> >>> Roger Quadros <rogerq@ti.com> wrote:
> >>>
> >>>> On 18/04/16 15:31, Roger Quadros wrote:
> >>>>> On 16/04/16 11:57, Boris Brezillon wrote:
> >>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
> >>>>>> Tony Lindgren <tony@atomide.com> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>> Or should I just pull this immutable branch in my current nand/next and
> >>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
> >>>>>>>> prevent conflicts when our branches are merged into linux-next, no
> >>>>>>>> matter the order.
> >>>>>>>
> >>>>>>> Ideally just one or more branches with just minimal changes in
> >>>>>>> them against -rc1. But you may have other dependencies in
> >>>>>>> your NAND tree so that may no longer be doable :) Usually if
> >>>>>>> I merge something that may need to get merged into other
> >>>>>>> branches, I just apply them into a separate branch against -rc1
> >>>>>>> to start with, then merge that branch in.
> >>>>>>
> >>>>>> Okay, in this case, that's pretty much what I did from the beginning,
> >>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
> >>>>>> Thanks for this detailed explanation, I'll try to remember that when
> >>>>>> I'll need to provide an immutable branch for another subsystem.
> >>>>>>
> >>>>>> Roger, my request remains, could you check/test my conflict resolution
> >>>>>> (branch nand/next-with-gpmc-rework)?
> >>>>>
> >>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
> >>>>> (at least on dra7-evm).
> >>>>>
> >>>>> The commit where it breaks is:
> >>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
> >>>>>
> >>>>> I'm trying to figure out what went wrong there. Failure log below.
> >>>>
> >>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
> >>>
> >>> Thanks for debugging that.
> >>>
> >>>>
> >>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
> >>>> the entire OOB region.
> >>>
> >>> Hm, it looks like there's a bug somewhere else, because I don't see any
> >>> reason why the controller wouldn't be able to read the full OOB region.
> >>
> >> The controller can read the full OOB region but we only want it to read just
> >> the ECC bytes because that is the way the ELM ECC engine works.
> >
> > Ok, I think I got it: the ECC correction is pipelined with data read,
> > and the controller expect to have ECC bytes right after the in-band
> > data, is that correct?
>
> That is correct.
>
> >
> >>
> >>>>
> >>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>>> index e622a1b..46b61d2 100644
> >>>> --- a/drivers/mtd/nand/omap2.c
> >>>> +++ b/drivers/mtd/nand/omap2.c
> >>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> >>>> chip->read_buf(mtd, buf, mtd->writesize);
> >>>>
> >>>> /* Read oob bytes */
> >>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> >>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
> >>>
> >>> The whole point of this series is to get rid of chip->ecc.layout, so
> >>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
> >>> chip->ecc.layout->eccpos[0].
> >>
> >> We just need the position of the first ECC byte offset.
> >> Is that the most optimal way to get it?
> >
> > For the BCH case, it seems that ECC bytes always start at offset
> > BADBLOCK_MARKER_LENGTH, so you can just pass
> > mtd->writesize + BADBLOCK_MARKER_LENGTH.
> >
> > Let me know if this works, and I'll squash those changes into the
> > faulty commit (I know this implies a rebase + push -f, but IMO that's
> > better than breaking bisectability).
> >
> >
>
> So, the below patch works as well. Please feel free to fold it with your patch.
>
> --
> cheers,
> -roger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index e622a1b..eb85d6b 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> chip->read_buf(mtd, buf, mtd->writesize);
>
> /* Read oob bytes */
> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
Are you sure this patch works? Cause it seems to me that it should be
chip->read_buf(mtd, chip->oob_poi + BADBLOCK_MARKER_LENGTH,
chip->ecc.total);
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
2016-04-19 13:22 ` Boris Brezillon
@ 2016-04-19 14:26 ` Roger Quadros
-1 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-19 14:26 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 19/04/16 16:22, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 17:39:01 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> On 18/04/16 17:10, Boris Brezillon wrote:
>>> On Mon, 18 Apr 2016 16:48:26 +0300
>>> Roger Quadros <rogerq@ti.com> wrote:
>>>
>>>> Boris,
>>>>
>>>> On 18/04/16 16:13, Boris Brezillon wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>>>> Roger Quadros <rogerq@ti.com> wrote:
>>>>>
>>>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>>>> matter the order.
>>>>>>>>>
>>>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>>>> I merge something that may need to get merged into other
>>>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>>>> to start with, then merge that branch in.
>>>>>>>>
>>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>>>
>>>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>>>
>>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>>>> (at least on dra7-evm).
>>>>>>>
>>>>>>> The commit where it breaks is:
>>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>>>
>>>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>>>
>>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>>>
>>>>> Thanks for debugging that.
>>>>>
>>>>>>
>>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>>>> the entire OOB region.
>>>>>
>>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>>>> reason why the controller wouldn't be able to read the full OOB region.
>>>>
>>>> The controller can read the full OOB region but we only want it to read just
>>>> the ECC bytes because that is the way the ELM ECC engine works.
>>>
>>> Ok, I think I got it: the ECC correction is pipelined with data read,
>>> and the controller expect to have ECC bytes right after the in-band
>>> data, is that correct?
>>
>> That is correct.
>>
>>>
>>>>
>>>>>>
>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>> index e622a1b..46b61d2 100644
>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>>>
>>>>>> /* Read oob bytes */
>>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>>>
>>>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>>>> chip->ecc.layout->eccpos[0].
>>>>
>>>> We just need the position of the first ECC byte offset.
>>>> Is that the most optimal way to get it?
>>>
>>> For the BCH case, it seems that ECC bytes always start at offset
>>> BADBLOCK_MARKER_LENGTH, so you can just pass
>>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>>>
>>> Let me know if this works, and I'll squash those changes into the
>>> faulty commit (I know this implies a rebase + push -f, but IMO that's
>>> better than breaking bisectability).
>>>
>>>
>>
>> So, the below patch works as well. Please feel free to fold it with your patch.
>>
>> --
>> cheers,
>> -roger
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index e622a1b..eb85d6b 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>> chip->read_buf(mtd, buf, mtd->writesize);
>>
>> /* Read oob bytes */
>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
>> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>
> Are you sure this patch works? Cause it seems to me that it should be
For my limited test case yes. My test case involves reading an existing ubifs partition
and creating a new one and then reading it back using an older kernel.
>
> chip->read_buf(mtd, chip->oob_poi + BADBLOCK_MARKER_LENGTH,
> chip->ecc.total);
>
You are right. Else we'd have wrong OOB data during reads.
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-19 14:26 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-19 14:26 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 19/04/16 16:22, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 17:39:01 +0300
> Roger Quadros <rogerq@ti.com> wrote:
>
>> On 18/04/16 17:10, Boris Brezillon wrote:
>>> On Mon, 18 Apr 2016 16:48:26 +0300
>>> Roger Quadros <rogerq@ti.com> wrote:
>>>
>>>> Boris,
>>>>
>>>> On 18/04/16 16:13, Boris Brezillon wrote:
>>>>> Hi Roger,
>>>>>
>>>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>>>> Roger Quadros <rogerq@ti.com> wrote:
>>>>>
>>>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>>>> matter the order.
>>>>>>>>>
>>>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>>>> I merge something that may need to get merged into other
>>>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>>>> to start with, then merge that branch in.
>>>>>>>>
>>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>>>
>>>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>>>
>>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>>>> (at least on dra7-evm).
>>>>>>>
>>>>>>> The commit where it breaks is:
>>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>>>
>>>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>>>
>>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>>>
>>>>> Thanks for debugging that.
>>>>>
>>>>>>
>>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>>>> the entire OOB region.
>>>>>
>>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>>>> reason why the controller wouldn't be able to read the full OOB region.
>>>>
>>>> The controller can read the full OOB region but we only want it to read just
>>>> the ECC bytes because that is the way the ELM ECC engine works.
>>>
>>> Ok, I think I got it: the ECC correction is pipelined with data read,
>>> and the controller expect to have ECC bytes right after the in-band
>>> data, is that correct?
>>
>> That is correct.
>>
>>>
>>>>
>>>>>>
>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>> index e622a1b..46b61d2 100644
>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>>>
>>>>>> /* Read oob bytes */
>>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>>>
>>>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>>>> chip->ecc.layout->eccpos[0].
>>>>
>>>> We just need the position of the first ECC byte offset.
>>>> Is that the most optimal way to get it?
>>>
>>> For the BCH case, it seems that ECC bytes always start at offset
>>> BADBLOCK_MARKER_LENGTH, so you can just pass
>>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>>>
>>> Let me know if this works, and I'll squash those changes into the
>>> faulty commit (I know this implies a rebase + push -f, but IMO that's
>>> better than breaking bisectability).
>>>
>>>
>>
>> So, the below patch works as well. Please feel free to fold it with your patch.
>>
>> --
>> cheers,
>> -roger
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index e622a1b..eb85d6b 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>> chip->read_buf(mtd, buf, mtd->writesize);
>>
>> /* Read oob bytes */
>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
>> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>
> Are you sure this patch works? Cause it seems to me that it should be
For my limited test case yes. My test case involves reading an existing ubifs partition
and creating a new one and then reading it back using an older kernel.
>
> chip->read_buf(mtd, chip->oob_poi + BADBLOCK_MARKER_LENGTH,
> chip->ecc.total);
>
You are right. Else we'd have wrong OOB data during reads.
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-19 14:49 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-19 14:49 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier, fcooper, nsekhar, linux-mtd, linux-omap,
computersforpeace, dwmw2, ezequiel, devicetree, linux-kernel
On 19/04/16 17:26, Roger Quadros wrote:
> On 19/04/16 16:22, Boris Brezillon wrote:
>> On Mon, 18 Apr 2016 17:39:01 +0300
>> Roger Quadros <rogerq@ti.com> wrote:
>>
>>> On 18/04/16 17:10, Boris Brezillon wrote:
>>>> On Mon, 18 Apr 2016 16:48:26 +0300
>>>> Roger Quadros <rogerq@ti.com> wrote:
>>>>
>>>>> Boris,
>>>>>
>>>>> On 18/04/16 16:13, Boris Brezillon wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>>>>> Roger Quadros <rogerq@ti.com> wrote:
>>>>>>
>>>>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>>>>> Tony Lindgren <tony@atomide.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>>>>> matter the order.
>>>>>>>>>>
>>>>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>>>>> I merge something that may need to get merged into other
>>>>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>>>>> to start with, then merge that branch in.
>>>>>>>>>
>>>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>>>>
>>>>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>>>>
>>>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>>>>> (at least on dra7-evm).
>>>>>>>>
>>>>>>>> The commit where it breaks is:
>>>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>>>>
>>>>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>>>>
>>>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>>>>
>>>>>> Thanks for debugging that.
>>>>>>
>>>>>>>
>>>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>>>>> the entire OOB region.
>>>>>>
>>>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>>>>> reason why the controller wouldn't be able to read the full OOB region.
>>>>>
>>>>> The controller can read the full OOB region but we only want it to read just
>>>>> the ECC bytes because that is the way the ELM ECC engine works.
>>>>
>>>> Ok, I think I got it: the ECC correction is pipelined with data read,
>>>> and the controller expect to have ECC bytes right after the in-band
>>>> data, is that correct?
>>>
>>> That is correct.
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>> index e622a1b..46b61d2 100644
>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>>>>
>>>>>>> /* Read oob bytes */
>>>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>>>>
>>>>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>>>>> chip->ecc.layout->eccpos[0].
>>>>>
>>>>> We just need the position of the first ECC byte offset.
>>>>> Is that the most optimal way to get it?
>>>>
>>>> For the BCH case, it seems that ECC bytes always start at offset
>>>> BADBLOCK_MARKER_LENGTH, so you can just pass
>>>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>>>>
>>>> Let me know if this works, and I'll squash those changes into the
>>>> faulty commit (I know this implies a rebase + push -f, but IMO that's
>>>> better than breaking bisectability).
>>>>
>>>>
>>>
>>> So, the below patch works as well. Please feel free to fold it with your patch.
>>>
>>> --
>>> cheers,
>>> -roger
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index e622a1b..eb85d6b 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>
>>> /* Read oob bytes */
>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
>>> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>>
>> Are you sure this patch works? Cause it seems to me that it should be
>
> For my limited test case yes. My test case involves reading an existing ubifs partition
> and creating a new one and then reading it back using an older kernel.
>
>>
>> chip->read_buf(mtd, chip->oob_poi + BADBLOCK_MARKER_LENGTH,
>> chip->ecc.total);
>>
>
> You are right. Else we'd have wrong OOB data during reads.
Strange, but nanddump is showing the correct OOB data with or without this
change. I'm puzzled.
--
cheers,
-roger
^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
@ 2016-04-19 14:49 ` Roger Quadros
0 siblings, 0 replies; 93+ messages in thread
From: Roger Quadros @ 2016-04-19 14:49 UTC (permalink / raw)
To: Boris Brezillon
Cc: Tony Lindgren, javier-0uQlZySMnqxg9hUCZPvPmw,
fcooper-l0cyMroinI0, nsekhar-l0cyMroinI0,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ezequiel-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On 19/04/16 17:26, Roger Quadros wrote:
> On 19/04/16 16:22, Boris Brezillon wrote:
>> On Mon, 18 Apr 2016 17:39:01 +0300
>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
>>
>>> On 18/04/16 17:10, Boris Brezillon wrote:
>>>> On Mon, 18 Apr 2016 16:48:26 +0300
>>>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
>>>>
>>>>> Boris,
>>>>>
>>>>> On 18/04/16 16:13, Boris Brezillon wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> On Mon, 18 Apr 2016 15:52:58 +0300
>>>>>> Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
>>>>>>
>>>>>>> On 18/04/16 15:31, Roger Quadros wrote:
>>>>>>>> On 16/04/16 11:57, Boris Brezillon wrote:
>>>>>>>>> On Fri, 15 Apr 2016 09:19:51 -0700
>>>>>>>>> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Or should I just pull this immutable branch in my current nand/next and
>>>>>>>>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>>>>>>>>> prevent conflicts when our branches are merged into linux-next, no
>>>>>>>>>>> matter the order.
>>>>>>>>>>
>>>>>>>>>> Ideally just one or more branches with just minimal changes in
>>>>>>>>>> them against -rc1. But you may have other dependencies in
>>>>>>>>>> your NAND tree so that may no longer be doable :) Usually if
>>>>>>>>>> I merge something that may need to get merged into other
>>>>>>>>>> branches, I just apply them into a separate branch against -rc1
>>>>>>>>>> to start with, then merge that branch in.
>>>>>>>>>
>>>>>>>>> Okay, in this case, that's pretty much what I did from the beginning,
>>>>>>>>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>>>>>>>>> Thanks for this detailed explanation, I'll try to remember that when
>>>>>>>>> I'll need to provide an immutable branch for another subsystem.
>>>>>>>>>
>>>>>>>>> Roger, my request remains, could you check/test my conflict resolution
>>>>>>>>> (branch nand/next-with-gpmc-rework)?
>>>>>>>>
>>>>>>>> I couldn't test that branch yet as nand/next is broken on omap platforms
>>>>>>>> (at least on dra7-evm).
>>>>>>>>
>>>>>>>> The commit where it breaks is:
>>>>>>>> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>>>>>>>>
>>>>>>>> I'm trying to figure out what went wrong there. Failure log below.
>>>>>>>
>>>>>>> OK. I was able to fix it when at commit a662ef4 with the below patch.
>>>>>>
>>>>>> Thanks for debugging that.
>>>>>>
>>>>>>>
>>>>>>> Looks like we need to read exactly the ECC bytes through the ECC engine and not
>>>>>>> the entire OOB region.
>>>>>>
>>>>>> Hm, it looks like there's a bug somewhere else, because I don't see any
>>>>>> reason why the controller wouldn't be able to read the full OOB region.
>>>>>
>>>>> The controller can read the full OOB region but we only want it to read just
>>>>> the ECC bytes because that is the way the ELM ECC engine works.
>>>>
>>>> Ok, I think I got it: the ECC correction is pipelined with data read,
>>>> and the controller expect to have ECC bytes right after the in-band
>>>> data, is that correct?
>>>
>>> That is correct.
>>>
>>>>
>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>> index e622a1b..46b61d2 100644
>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>>>>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>>>>>
>>>>>>> /* Read oob bytes */
>>>>>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>>>>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>>>>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
>>>>>>
>>>>>> The whole point of this series is to get rid of chip->ecc.layout, so
>>>>>> we'd rather use the mtd_ooblayout_find_eccregion() instead of
>>>>>> chip->ecc.layout->eccpos[0].
>>>>>
>>>>> We just need the position of the first ECC byte offset.
>>>>> Is that the most optimal way to get it?
>>>>
>>>> For the BCH case, it seems that ECC bytes always start at offset
>>>> BADBLOCK_MARKER_LENGTH, so you can just pass
>>>> mtd->writesize + BADBLOCK_MARKER_LENGTH.
>>>>
>>>> Let me know if this works, and I'll squash those changes into the
>>>> faulty commit (I know this implies a rebase + push -f, but IMO that's
>>>> better than breaking bisectability).
>>>>
>>>>
>>>
>>> So, the below patch works as well. Please feel free to fold it with your patch.
>>>
>>> --
>>> cheers,
>>> -roger
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index e622a1b..eb85d6b 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
>>> chip->read_buf(mtd, buf, mtd->writesize);
>>>
>>> /* Read oob bytes */
>>> - chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
>>> - chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
>>> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + BADBLOCK_MARKER_LENGTH, -1);
>>> + chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
>>
>> Are you sure this patch works? Cause it seems to me that it should be
>
> For my limited test case yes. My test case involves reading an existing ubifs partition
> and creating a new one and then reading it back using an older kernel.
>
>>
>> chip->read_buf(mtd, chip->oob_poi + BADBLOCK_MARKER_LENGTH,
>> chip->ecc.total);
>>
>
> You are right. Else we'd have wrong OOB data during reads.
Strange, but nanddump is showing the correct OOB data with or without this
change. I'm puzzled.
--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 93+ messages in thread