Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1373231 > unrolled thread

[PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

Back to article view | Back to linux.kernel

Contents

  [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 10/17] mtd: nand: omap: Update DT binding documentation Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 16/17] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 09/17] mtd: nand: omap: Clean up device tree support Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 14/17] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 03/17] memory: omap-gpmc: Introduce GPMC to NAND interface Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for NAND IRQs Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
      Re: [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for  NAND IRQs Rob Herring <robh@kernel.org> - 2016-04-11 17:00 +0200
    [PATCH v6 06/17] mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 13/17] memory: omap-gpmc: Support general purpose input for WAITPINs Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
      Re: [PATCH v6 13/17] memory: omap-gpmc: Support general purpose  input for WAITPINs Rob Herring <robh@kernel.org> - 2016-04-11 17:10 +0200
    [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using gpiolib Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
      Re: [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using  gpiolib Rob Herring <robh@kernel.org> - 2016-04-11 17:10 +0200
    [PATCH v6 07/17] mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty check Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 11/17] memory: omap-gpmc: Prevent mapping into 1st 16MB Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 08/17] mtd: nand: omap: Copy platform data parameters to omap_nand_info data Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 01/17] ARM: OMAP2+: gpmc: Add platform data Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 04/17] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge interrupts Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
      Re: [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge  interrupts Rob Herring <robh@kernel.org> - 2016-04-11 17:10 +0200
    [PATCH v6 02/17] ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    [PATCH v6 12/17] memory: omap-gpmc: Move device tree binding to correct location Roger Quadros <rogerq@ti.com> - 2016-04-07 12:20 +0200
    Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND  on non-OMAP platforms Tony Lindgren <tony@atomide.com> - 2016-04-13 23:30 +0200
      Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND  on non-OMAP platforms Roger Quadros <rogerq@ti.com> - 2016-04-15 11:40 +0200
        Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC  NAND on non-OMAP platforms Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-04-15 12:10 +0200
          Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND  on non-OMAP platforms Roger Quadros <rogerq@ti.com> - 2016-04-15 13:00 +0200
            Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC  NAND on non-OMAP platforms Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-04-15 13:20 +0200
            Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC  NAND on non-OMAP platforms Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-04-15 14:00 +0200
              Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND  on non-OMAP platforms Tony Lindgren <tony@atomide.com> - 2016-04-15 17:50 +0200
                Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC  NAND on non-OMAP platforms Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-04-15 18:10 +0200
                  Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND  on non-OMAP platforms Tony Lindgren <tony@atomide.com> - 2016-04-15 18:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1373249 — [PATCH v6 02/17] ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data

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

[toc] | [prev] | [next] | [standalone]

#1373250 — [PATCH v6 12/17] memory: omap-gpmc: Move device tree binding to correct location

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

[toc] | [prev] | [next] | [standalone]

#1378302 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

* 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>

[toc] | [prev] | [next] | [standalone]

#1379645 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

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

[toc] | [prev] | [next] | [standalone]

#1379660 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

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

[toc] | [prev] | [next] | [standalone]

#1379724 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

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
> 
> 

[toc] | [prev] | [next] | [standalone]

#1379749 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

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

[toc] | [prev] | [next] | [standalone]

#1379771 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

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

[toc] | [prev] | [next] | [standalone]

#1379931 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

* 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

[toc] | [prev] | [next] | [standalone]

#1379956 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

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

[toc] | [prev] | [next] | [standalone]

#1379982 — Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

* 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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web