[PATCH 0/4] OMAP-GPMC generic timing migration

[PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi,

This series provides a generic gpmc timing calculation routine. There
were three peripherals (OneNAND, tusb6010, smc91x) using custom timing
calculations, they are migrated to use the generic timing calculation.

Such a generic routine would help create a driver out of gpmc platform
code, which would be peripheral agnostic and thus lead to DT finally.
Input to generic timing calculation routine would be gpmc peripheral
timings, output - translated timings that gpmc can understand. Later,
to DT'ify, gpmc peripheral timings could be passed through DT. Input
timings that has been used here are selected such that it represents
those that are present in peripheral timing datasheets.

This series has been created by pulling out last 4 patches in v7
of the series,
"OMAP-GPMC: generic time calc, prepare for driver"
This was done to have easy path for common zImage gpmc cleanup patches.

Proposed generic routine has been tested on OneNAND (async) on
OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
local patch were used to test). For other cases of custom timing
calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
calculation routine was verified by simulating on OMAP3EVM.

This series is available
        @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1
and is based on
        linux-next (next-20121005)
and is dependent on
	http://marc.info/?l=linux-omap&m=134945131602622&w=2
	http://marc.info/?l=linux-omap&m=134945239306131&w=2

This series as such is only the first version, but these patches has
already undergone one change before being made as this series. The
change was in using ps instead of ns to prevent rounding errors.
Also along with this series documentation has been improved.

Regards
Afzal


Afzal Mohammed (4):
  ARM: OMAP2+: gpmc: generic timing calculation
  ARM: OMAP2+: onenand: generic timing calculation
  ARM: OMAP2+: smc91x: generic timing calculation
  ARM: OMAP2+: tusb6010: generic timing calculation

 Documentation/bus-devices/ti-gpmc.txt | 122 +++++++++++++
 arch/arm/mach-omap2/gpmc-onenand.c    | 124 +++++--------
 arch/arm/mach-omap2/gpmc-smc91x.c     |  43 ++---
 arch/arm/mach-omap2/gpmc.c            | 325 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/gpmc.h            | 102 ++++++++---
 arch/arm/mach-omap2/usb-tusb6010.c    | 182 +++++--------------
 6 files changed, 633 insertions(+), 265 deletions(-)
 create mode 100644 Documentation/bus-devices/ti-gpmc.txt

-- 
1.7.12

[PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi,

This series provides a generic gpmc timing calculation routine. There
were three peripherals (OneNAND, tusb6010, smc91x) using custom timing
calculations, they are migrated to use the generic timing calculation.

Such a generic routine would help create a driver out of gpmc platform
code, which would be peripheral agnostic and thus lead to DT finally.
Input to generic timing calculation routine would be gpmc peripheral
timings, output - translated timings that gpmc can understand. Later,
to DT'ify, gpmc peripheral timings could be passed through DT. Input
timings that has been used here are selected such that it represents
those that are present in peripheral timing datasheets.

This series has been created by pulling out last 4 patches in v7
of the series,
"OMAP-GPMC: generic time calc, prepare for driver"
This was done to have easy path for common zImage gpmc cleanup patches.

Proposed generic routine has been tested on OneNAND (async) on
OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
local patch were used to test). For other cases of custom timing
calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
calculation routine was verified by simulating on OMAP3EVM.

This series is available
        @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1
and is based on
        linux-next (next-20121005)
and is dependent on
	http://marc.info/?l=linux-omap&m=134945131602622&w=2
	http://marc.info/?l=linux-omap&m=134945239306131&w=2

This series as such is only the first version, but these patches has
already undergone one change before being made as this series. The
change was in using ps instead of ns to prevent rounding errors.
Also along with this series documentation has been improved.

Regards
Afzal


Afzal Mohammed (4):
  ARM: OMAP2+: gpmc: generic timing calculation
  ARM: OMAP2+: onenand: generic timing calculation
  ARM: OMAP2+: smc91x: generic timing calculation
  ARM: OMAP2+: tusb6010: generic timing calculation

 Documentation/bus-devices/ti-gpmc.txt | 122 +++++++++++++
 arch/arm/mach-omap2/gpmc-onenand.c    | 124 +++++--------
 arch/arm/mach-omap2/gpmc-smc91x.c     |  43 ++---
 arch/arm/mach-omap2/gpmc.c            | 325 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/gpmc.h            | 102 ++++++++---
 arch/arm/mach-omap2/usb-tusb6010.c    | 182 +++++--------------
 6 files changed, 633 insertions(+), 265 deletions(-)
 create mode 100644 Documentation/bus-devices/ti-gpmc.txt

-- 
1.7.12

[PATCH 1/4] ARM: OMAP2+: gpmc: generic timing calculation

[Afzal Mohammed]

Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.

Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.

There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.

Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.

It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.

Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.

Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 Documentation/bus-devices/ti-gpmc.txt | 122 +++++++++++++
 arch/arm/mach-omap2/gpmc.c            | 325 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/gpmc.h            | 102 ++++++++---
 3 files changed, 529 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/bus-devices/ti-gpmc.txt

diff --git a/Documentation/bus-devices/ti-gpmc.txt b/Documentation/bus-devices/ti-gpmc.txt
new file mode 100644
index 0000000..cc9ce57
--- /dev/null
+++ b/Documentation/bus-devices/ti-gpmc.txt
@@ -0,0 +1,122 @@
+GPMC (General Purpose Memory Controller):
+=========================================
+
+GPMC is an unified memory controller dedicated to interfacing external
+memory devices like
+ * Asynchronous SRAM like memories and application specific integrated
+   circuit devices.
+ * Asynchronous, synchronous, and page mode burst NOR flash devices
+   NAND flash
+ * Pseudo-SRAM devices
+
+GPMC is found on Texas Instruments SoC's (OMAP based)
+IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1
+
+
+GPMC generic timing calculation:
+================================
+
+GPMC has certain timings that has to be programmed for proper
+functioning of the peripheral, while peripheral has another set of
+timings. To have peripheral work with gpmc, peripheral timings has to
+be translated to the form gpmc can understand. The way it has to be
+translated depends on the connected peripheral. Also there is a
+dependency for certain gpmc timings on gpmc clock frequency. Hence a
+generic timing routine was developed to achieve above requirements.
+
+Generic routine provides a generic method to calculate gpmc timings
+from gpmc peripheral timings. struct gpmc_device_timings fields has to
+be updated with timings from the datasheet of the peripheral that is
+connected to gpmc. A few of the peripheral timings can be fed either
+in time or in cycles, provision to handle this scenario has been
+provided (refer struct gpmc_device_timings definition). It may so
+happen that timing as specified by peripheral datasheet is not present
+in timing structure, in this scenario, try to correlate peripheral
+timing to the one available. If that doesn't work, try to add a new
+field as required by peripheral, educate generic timing routine to
+handle it, make sure that it does not break any of the existing.
+Then there may be cases where peripheral datasheet doesn't mention
+certain fields of struct gpmc_device_timings, zero those entries.
+
+Generic timing routine has been verified to work properly on
+multiple onenand's and tusb6010 peripherals.
+
+A word of caution: generic timing routine has been developed based
+on understanding of gpmc timings, peripheral timings, available
+custom timing routines, a kind of reverse engineering without
+most of the datasheets & hardware (to be exact none of those supported
+in mainline having custom timing routine) and by simulation.
+
+gpmc timing dependency on peripheral timings:
+[<gpmc_timing>: <peripheral timing1>, <peripheral timing2> ...]
+
+1. common
+cs_on: t_ceasu
+adv_on: t_avdasu, t_ceavd
+
+2. sync common
+sync_clk: clk
+page_burst_access: t_bacc
+clk_activation: t_ces, t_avds
+
+3. read async muxed
+adv_rd_off: t_avdp_r
+oe_on: t_oeasu, t_aavdh
+access: t_iaa, t_oe, t_ce, t_aa
+rd_cycle: t_rd_cycle, t_cez_r, t_oez
+
+4. read async non-muxed
+adv_rd_off: t_avdp_r
+oe_on: t_oeasu
+access: t_iaa, t_oe, t_ce, t_aa
+rd_cycle: t_rd_cycle, t_cez_r, t_oez
+
+5. read sync muxed
+adv_rd_off: t_avdp_r, t_avdh
+oe_on: t_oeasu, t_ach, cyc_aavdh_oe
+access: t_iaa, cyc_iaa, cyc_oe
+rd_cycle: t_cez_r, t_oez, t_ce_rdyz
+
+6. read sync non-muxed
+adv_rd_off: t_avdp_r
+oe_on: t_oeasu
+access: t_iaa, cyc_iaa, cyc_oe
+rd_cycle: t_cez_r, t_oez, t_ce_rdyz
+
+7. write async muxed
+adv_wr_off: t_avdp_w
+we_on, wr_data_mux_bus: t_weasu, t_aavdh, cyc_aavhd_we
+we_off: t_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_wr_cycle
+
+8. write async non-muxed
+adv_wr_off: t_avdp_w
+we_on, wr_data_mux_bus: t_weasu
+we_off: t_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_wr_cycle
+
+9. write sync muxed
+adv_wr_off: t_avdp_w, t_avdh
+we_on, wr_data_mux_bus: t_weasu, t_rdyo, t_aavdh, cyc_aavhd_we
+we_off: t_wpl, cyc_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_ce_rdyz
+
+10. write sync non-muxed
+adv_wr_off: t_avdp_w
+we_on, wr_data_mux_bus: t_weasu, t_rdyo
+we_off: t_wpl, cyc_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_ce_rdyz
+
+
+Note: Many of gpmc timings are dependent on other gpmc timings (a few
+gpmc timings purely dependent on other gpmc timings, a reason that
+some of the gpmc timings are missing above), and it will result in
+indirect dependency of peripheral timings to gpmc timings other than
+mentioned above, refer timing routine for more details. To know what
+these peripheral timings correspond to, please see explanations in
+struct gpmc_device_timings definition. And for gpmc timings refer
+IP details (link above).
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 285070e..4c203ce 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -233,6 +233,18 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
 	return ticks * gpmc_get_fclk_period() / 1000;
 }
 
+static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
+{
+	return ticks * gpmc_get_fclk_period();
+}
+
+static unsigned int gpmc_round_ps_to_ticks(unsigned int time_ps)
+{
+	unsigned long ticks = gpmc_ps_to_ticks(time_ps);
+
+	return ticks * gpmc_get_fclk_period();
+}
+
 static inline void gpmc_cs_modify_reg(int cs, int reg, u32 mask, bool value)
 {
 	u32 l;
@@ -792,6 +804,319 @@ static void __devinit gpmc_mem_init(void)
 	}
 }
 
+static u32 gpmc_round_ps_to_sync_clk(u32 time_ps, u32 sync_clk)
+{
+	u32 temp;
+	int div;
+
+	div = gpmc_calc_divider(sync_clk);
+	temp = gpmc_ps_to_ticks(time_ps);
+	temp = (temp + div - 1) / div;
+	return gpmc_ticks_to_ps(temp * div);
+}
+
+/* XXX: can the cycles be avoided ? */
+static int gpmc_calc_sync_read_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_rd_off */
+	temp = dev_t->t_avdp_r;
+	/* XXX: mux check required ? */
+	if (mux) {
+		/* XXX: t_avdp not to be required for sync, only added for tusb
+		 * this indirectly necessitates requirement of t_avdp_r and
+		 * t_avdp_w instead of having a single t_avdp
+		 */
+		temp = max_t(u32, temp,	gpmc_t->clk_activation + dev_t->t_avdh);
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	}
+	gpmc_t->adv_rd_off = gpmc_round_ps_to_ticks(temp);
+
+	/* oe_on */
+	temp = dev_t->t_oeasu; /* XXX: remove this ? */
+	if (mux) {
+		temp = max_t(u32, temp,	gpmc_t->clk_activation + dev_t->t_ach);
+		temp = max_t(u32, temp, gpmc_t->adv_rd_off +
+				gpmc_ticks_to_ps(dev_t->cyc_aavdh_oe));
+	}
+	gpmc_t->oe_on = gpmc_round_ps_to_ticks(temp);
+
+	/* access */
+	/* XXX: any scope for improvement ?, by combining oe_on
+	 * and clk_activation, need to check whether
+	 * access = clk_activation + round to sync clk ?
+	 */
+	temp = max_t(u32, dev_t->t_iaa,	dev_t->cyc_iaa * gpmc_t->sync_clk);
+	temp += gpmc_t->clk_activation;
+	if (dev_t->cyc_oe)
+		temp = max_t(u32, temp, gpmc_t->oe_on +
+				gpmc_ticks_to_ps(dev_t->cyc_oe));
+	gpmc_t->access = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->oe_off = gpmc_t->access + gpmc_ticks_to_ps(1);
+	gpmc_t->cs_rd_off = gpmc_t->oe_off;
+
+	/* rd_cycle */
+	temp = max_t(u32, dev_t->t_cez_r, dev_t->t_oez);
+	temp = gpmc_round_ps_to_sync_clk(temp, gpmc_t->sync_clk) +
+							gpmc_t->access;
+	/* XXX: barter t_ce_rdyz with t_cez_r ? */
+	if (dev_t->t_ce_rdyz)
+		temp = max_t(u32, temp,	gpmc_t->cs_rd_off + dev_t->t_ce_rdyz);
+	gpmc_t->rd_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_sync_write_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_wr_off */
+	temp = dev_t->t_avdp_w;
+	if (mux) {
+		temp = max_t(u32, temp,
+			gpmc_t->clk_activation + dev_t->t_avdh);
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	}
+	gpmc_t->adv_wr_off = gpmc_round_ps_to_ticks(temp);
+
+	/* wr_data_mux_bus */
+	temp = max_t(u32, dev_t->t_weasu,
+			gpmc_t->clk_activation + dev_t->t_rdyo);
+	/* XXX: shouldn't mux be kept as a whole for wr_data_mux_bus ?,
+	 * and in that case remember to handle we_on properly
+	 */
+	if (mux) {
+		temp = max_t(u32, temp,
+			gpmc_t->adv_wr_off + dev_t->t_aavdh);
+		temp = max_t(u32, temp, gpmc_t->adv_wr_off +
+				gpmc_ticks_to_ps(dev_t->cyc_aavdh_we));
+	}
+	gpmc_t->wr_data_mux_bus = gpmc_round_ps_to_ticks(temp);
+
+	/* we_on */
+	if (gpmc_capability & GPMC_HAS_WR_DATA_MUX_BUS)
+		gpmc_t->we_on = gpmc_round_ps_to_ticks(dev_t->t_weasu);
+	else
+		gpmc_t->we_on = gpmc_t->wr_data_mux_bus;
+
+	/* wr_access */
+	/* XXX: gpmc_capability check reqd ? , even if not, will not harm */
+	gpmc_t->wr_access = gpmc_t->access;
+
+	/* we_off */
+	temp = gpmc_t->we_on + dev_t->t_wpl;
+	temp = max_t(u32, temp,
+			gpmc_t->wr_access + gpmc_ticks_to_ps(1));
+	temp = max_t(u32, temp,
+		gpmc_t->we_on + gpmc_ticks_to_ps(dev_t->cyc_wpl));
+	gpmc_t->we_off = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->cs_wr_off = gpmc_round_ps_to_ticks(gpmc_t->we_off +
+							dev_t->t_wph);
+
+	/* wr_cycle */
+	temp = gpmc_round_ps_to_sync_clk(dev_t->t_cez_w, gpmc_t->sync_clk);
+	temp += gpmc_t->wr_access;
+	/* XXX: barter t_ce_rdyz with t_cez_w ? */
+	if (dev_t->t_ce_rdyz)
+		temp = max_t(u32, temp,
+				 gpmc_t->cs_wr_off + dev_t->t_ce_rdyz);
+	gpmc_t->wr_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_async_read_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_rd_off */
+	temp = dev_t->t_avdp_r;
+	if (mux)
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	gpmc_t->adv_rd_off = gpmc_round_ps_to_ticks(temp);
+
+	/* oe_on */
+	temp = dev_t->t_oeasu;
+	if (mux)
+		temp = max_t(u32, temp,
+			gpmc_t->adv_rd_off + dev_t->t_aavdh);
+	gpmc_t->oe_on = gpmc_round_ps_to_ticks(temp);
+
+	/* access */
+	temp = max_t(u32, dev_t->t_iaa, /* XXX: remove t_iaa in async ? */
+				gpmc_t->oe_on + dev_t->t_oe);
+	temp = max_t(u32, temp,
+				gpmc_t->cs_on + dev_t->t_ce);
+	temp = max_t(u32, temp,
+				gpmc_t->adv_on + dev_t->t_aa);
+	gpmc_t->access = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->oe_off = gpmc_t->access + gpmc_ticks_to_ps(1);
+	gpmc_t->cs_rd_off = gpmc_t->oe_off;
+
+	/* rd_cycle */
+	temp = max_t(u32, dev_t->t_rd_cycle,
+			gpmc_t->cs_rd_off + dev_t->t_cez_r);
+	temp = max_t(u32, temp, gpmc_t->oe_off + dev_t->t_oez);
+	gpmc_t->rd_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_async_write_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_wr_off */
+	temp = dev_t->t_avdp_w;
+	if (mux)
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	gpmc_t->adv_wr_off = gpmc_round_ps_to_ticks(temp);
+
+	/* wr_data_mux_bus */
+	temp = dev_t->t_weasu;
+	if (mux) {
+		temp = max_t(u32, temp,	gpmc_t->adv_wr_off + dev_t->t_aavdh);
+		temp = max_t(u32, temp, gpmc_t->adv_wr_off +
+				gpmc_ticks_to_ps(dev_t->cyc_aavdh_we));
+	}
+	gpmc_t->wr_data_mux_bus = gpmc_round_ps_to_ticks(temp);
+
+	/* we_on */
+	if (gpmc_capability & GPMC_HAS_WR_DATA_MUX_BUS)
+		gpmc_t->we_on = gpmc_round_ps_to_ticks(dev_t->t_weasu);
+	else
+		gpmc_t->we_on = gpmc_t->wr_data_mux_bus;
+
+	/* we_off */
+	temp = gpmc_t->we_on + dev_t->t_wpl;
+	gpmc_t->we_off = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->cs_wr_off = gpmc_round_ps_to_ticks(gpmc_t->we_off +
+							dev_t->t_wph);
+
+	/* wr_cycle */
+	temp = max_t(u32, dev_t->t_wr_cycle,
+				gpmc_t->cs_wr_off + dev_t->t_cez_w);
+	gpmc_t->wr_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_sync_common_timings(struct gpmc_timings *gpmc_t,
+			struct gpmc_device_timings *dev_t)
+{
+	u32 temp;
+
+	gpmc_t->sync_clk = gpmc_calc_divider(dev_t->clk) *
+						gpmc_get_fclk_period();
+
+	gpmc_t->page_burst_access = gpmc_round_ps_to_sync_clk(
+					dev_t->t_bacc,
+					gpmc_t->sync_clk);
+
+	temp = max_t(u32, dev_t->t_ces, dev_t->t_avds);
+	gpmc_t->clk_activation = gpmc_round_ps_to_ticks(temp);
+
+	if (gpmc_calc_divider(gpmc_t->sync_clk) != 1)
+		return 0;
+
+	if (dev_t->ce_xdelay)
+		gpmc_t->bool_timings.cs_extra_delay = true;
+	if (dev_t->avd_xdelay)
+		gpmc_t->bool_timings.adv_extra_delay = true;
+	if (dev_t->oe_xdelay)
+		gpmc_t->bool_timings.oe_extra_delay = true;
+	if (dev_t->we_xdelay)
+		gpmc_t->bool_timings.we_extra_delay = true;
+
+	return 0;
+}
+
+static int gpmc_calc_common_timings(struct gpmc_timings *gpmc_t,
+			struct gpmc_device_timings *dev_t)
+{
+	u32 temp;
+
+	/* cs_on */
+	gpmc_t->cs_on = gpmc_round_ps_to_ticks(dev_t->t_ceasu);
+
+	/* adv_on */
+	temp = dev_t->t_avdasu;
+	if (dev_t->t_ce_avd)
+		temp = max_t(u32, temp,
+				gpmc_t->cs_on + dev_t->t_ce_avd);
+	gpmc_t->adv_on = gpmc_round_ps_to_ticks(temp);
+
+	if (dev_t->sync_write || dev_t->sync_read)
+		gpmc_calc_sync_common_timings(gpmc_t, dev_t);
+
+	return 0;
+}
+
+/* TODO: remove this function once all peripherals are confirmed to
+ * work with generic timing. Simultaneously gpmc_cs_set_timings()
+ * has to be modified to handle timings in ps instead of ns
+*/
+static void gpmc_convert_ps_to_ns(struct gpmc_timings *t)
+{
+	t->cs_on /= 1000;
+	t->cs_rd_off /= 1000;
+	t->cs_wr_off /= 1000;
+	t->adv_on /= 1000;
+	t->adv_rd_off /= 1000;
+	t->adv_wr_off /= 1000;
+	t->we_on /= 1000;
+	t->we_off /= 1000;
+	t->oe_on /= 1000;
+	t->oe_off /= 1000;
+	t->page_burst_access /= 1000;
+	t->access /= 1000;
+	t->rd_cycle /= 1000;
+	t->wr_cycle /= 1000;
+	t->bus_turnaround /= 1000;
+	t->cycle2cycle_delay /= 1000;
+	t->wait_monitoring /= 1000;
+	t->clk_activation /= 1000;
+	t->wr_access /= 1000;
+	t->wr_data_mux_bus /= 1000;
+}
+
+int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
+			struct gpmc_device_timings *dev_t)
+{
+	memset(gpmc_t, 0, sizeof(*gpmc_t));
+
+	gpmc_calc_common_timings(gpmc_t, dev_t);
+
+	if (dev_t->sync_read)
+		gpmc_calc_sync_read_timings(gpmc_t, dev_t);
+	else
+		gpmc_calc_async_read_timings(gpmc_t, dev_t);
+
+	if (dev_t->sync_write)
+		gpmc_calc_sync_write_timings(gpmc_t, dev_t);
+	else
+		gpmc_calc_async_write_timings(gpmc_t, dev_t);
+
+	/* TODO: remove, see function definition */
+	gpmc_convert_ps_to_ns(gpmc_t);
+
+	return 0;
+}
+
 static __devinit int gpmc_probe(struct platform_device *pdev)
 {
 	u32 l;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index e08a51a..fe0a844 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -94,42 +94,104 @@ struct gpmc_timings {
 	u32 sync_clk;
 
 	/* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
-	u16 cs_on;		/* Assertion time */
-	u16 cs_rd_off;		/* Read deassertion time */
-	u16 cs_wr_off;		/* Write deassertion time */
+	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 */
-	u16 adv_on;		/* Assertion time */
-	u16 adv_rd_off;		/* Read deassertion time */
-	u16 adv_wr_off;		/* Write deassertion time */
+	u32 adv_on;		/* Assertion time */
+	u32 adv_rd_off;		/* Read deassertion time */
+	u32 adv_wr_off;		/* Write deassertion time */
 
 	/* WE signals timings corresponding to GPMC_CONFIG4 */
-	u16 we_on;		/* WE assertion time */
-	u16 we_off;		/* WE deassertion time */
+	u32 we_on;		/* WE assertion time */
+	u32 we_off;		/* WE deassertion time */
 
 	/* OE signals timings corresponding to GPMC_CONFIG4 */
-	u16 oe_on;		/* OE assertion time */
-	u16 oe_off;		/* OE deassertion time */
+	u32 oe_on;		/* OE assertion time */
+	u32 oe_off;		/* OE deassertion time */
 
 	/* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
-	u16 page_burst_access;	/* Multiple access word delay */
-	u16 access;		/* Start-cycle to first data valid delay */
-	u16 rd_cycle;		/* Total read cycle time */
-	u16 wr_cycle;		/* Total write cycle time */
+	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 */
 
-	u16 bus_turnaround;
-	u16 cycle2cycle_delay;
+	u32 bus_turnaround;
+	u32 cycle2cycle_delay;
 
-	u16 wait_monitoring;
-	u16 clk_activation;
+	u32 wait_monitoring;
+	u32 clk_activation;
 
 	/* The following are only on OMAP3430 */
-	u16 wr_access;		/* WRACCESSTIME */
-	u16 wr_data_mux_bus;	/* WRDATAONADMUXBUS */
+	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 */
+
+	bool mux;	/* address & data muxed */
+	bool sync_write;/* synchronous write */
+	bool sync_read;	/* synchronous read */
+
+	/* extra delays */
+	bool ce_xdelay;
+	bool avd_xdelay;
+	bool oe_xdelay;
+	bool we_xdelay;
+};
+
+extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t);
+
 extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
 extern int gpmc_get_client_irq(unsigned irq_config);
 
-- 
1.7.12

[PATCH 1/4] ARM: OMAP2+: gpmc: generic timing calculation

[Afzal Mohammed]

Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.

Here a generic runtime calculation method is proposed. Input
to this function were selected so that they represent timing
variables that are present in peripheral datasheets. Motive
behind this was to achieve DT bindings for the inputs as is.
Even though a few of the tusb6010 timings could not be made
directly related to timings normally found on peripherals,
expressions used were translated to those that could be
justified.

There are possibilities of improving the calculations, like
calculating timing for read & write operations in a more
similar way. Expressions derived here were tested for async
onenand on omap3evm (as vanilla Kernel does not have omap3evm
onenand support, local patch was used). Other peripherals,
tusb6010, smc91x calculations were validated by simulating
on omap3evm.

Regarding "we_on" for onenand async, it was found that even
for muxed address/data, it need not be greater than
"adv_wr_off", but rather could be derived from write setup
time for peripheral from start of access time, hence would
more be in line with peripheral timings. With this method
it was working fine. If it is required in some cases to
have "we_on" same as "wr_data_mux_bus" (i.e. greater than
"adv_wr_off"), another variable could be added to indicate
it. But such a requirement is not expected though.

It has been observed that "adv_rd_off" & "adv_wr_off" are
currently calculated by adding an offset over "oe_on" and
"we_on" respectively in the case of smc91x. But peripheral
datasheet does not specify so and so "adv_rd(wr)_off" has
been derived (to be specific, made ignorant of "oe_on" and
"we_on") observing datasheet rather than adding an offset.
Hence this generic routine is expected to work for smc91x
(91C96 RX51 board). This was verified on smsc911x (9220 on
OMAP3EVM) - a similar ethernet controller.

Timings are calculated in ps to prevent rounding errors and
converted to ns at final stage so that these values can be
directly fed to gpmc_cs_set_timings(). gpmc_cs_set_timings()
would be modified to take ps once all custom timing routines
are replaced by the generic routine, at the same time
generic timing routine would be modified to provide timings
in ps. struct gpmc_timings field types are upgraded from
u16 => u32 so that it can hold ps values.

Whole of this exercise is being done to achieve driver and
DT conversion. If timings could not be calculated in a
peripheral agnostic way, either gpmc driver would have to
be peripheral gnostic or a wrapper arrangement over gpmc
driver would be required.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 Documentation/bus-devices/ti-gpmc.txt | 122 +++++++++++++
 arch/arm/mach-omap2/gpmc.c            | 325 ++++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/gpmc.h            | 102 ++++++++---
 3 files changed, 529 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/bus-devices/ti-gpmc.txt

diff --git a/Documentation/bus-devices/ti-gpmc.txt b/Documentation/bus-devices/ti-gpmc.txt
new file mode 100644
index 0000000..cc9ce57
--- /dev/null
+++ b/Documentation/bus-devices/ti-gpmc.txt
@@ -0,0 +1,122 @@
+GPMC (General Purpose Memory Controller):
+=========================================
+
+GPMC is an unified memory controller dedicated to interfacing external
+memory devices like
+ * Asynchronous SRAM like memories and application specific integrated
+   circuit devices.
+ * Asynchronous, synchronous, and page mode burst NOR flash devices
+   NAND flash
+ * Pseudo-SRAM devices
+
+GPMC is found on Texas Instruments SoC's (OMAP based)
+IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1
+
+
+GPMC generic timing calculation:
+================================
+
+GPMC has certain timings that has to be programmed for proper
+functioning of the peripheral, while peripheral has another set of
+timings. To have peripheral work with gpmc, peripheral timings has to
+be translated to the form gpmc can understand. The way it has to be
+translated depends on the connected peripheral. Also there is a
+dependency for certain gpmc timings on gpmc clock frequency. Hence a
+generic timing routine was developed to achieve above requirements.
+
+Generic routine provides a generic method to calculate gpmc timings
+from gpmc peripheral timings. struct gpmc_device_timings fields has to
+be updated with timings from the datasheet of the peripheral that is
+connected to gpmc. A few of the peripheral timings can be fed either
+in time or in cycles, provision to handle this scenario has been
+provided (refer struct gpmc_device_timings definition). It may so
+happen that timing as specified by peripheral datasheet is not present
+in timing structure, in this scenario, try to correlate peripheral
+timing to the one available. If that doesn't work, try to add a new
+field as required by peripheral, educate generic timing routine to
+handle it, make sure that it does not break any of the existing.
+Then there may be cases where peripheral datasheet doesn't mention
+certain fields of struct gpmc_device_timings, zero those entries.
+
+Generic timing routine has been verified to work properly on
+multiple onenand's and tusb6010 peripherals.
+
+A word of caution: generic timing routine has been developed based
+on understanding of gpmc timings, peripheral timings, available
+custom timing routines, a kind of reverse engineering without
+most of the datasheets & hardware (to be exact none of those supported
+in mainline having custom timing routine) and by simulation.
+
+gpmc timing dependency on peripheral timings:
+[<gpmc_timing>: <peripheral timing1>, <peripheral timing2> ...]
+
+1. common
+cs_on: t_ceasu
+adv_on: t_avdasu, t_ceavd
+
+2. sync common
+sync_clk: clk
+page_burst_access: t_bacc
+clk_activation: t_ces, t_avds
+
+3. read async muxed
+adv_rd_off: t_avdp_r
+oe_on: t_oeasu, t_aavdh
+access: t_iaa, t_oe, t_ce, t_aa
+rd_cycle: t_rd_cycle, t_cez_r, t_oez
+
+4. read async non-muxed
+adv_rd_off: t_avdp_r
+oe_on: t_oeasu
+access: t_iaa, t_oe, t_ce, t_aa
+rd_cycle: t_rd_cycle, t_cez_r, t_oez
+
+5. read sync muxed
+adv_rd_off: t_avdp_r, t_avdh
+oe_on: t_oeasu, t_ach, cyc_aavdh_oe
+access: t_iaa, cyc_iaa, cyc_oe
+rd_cycle: t_cez_r, t_oez, t_ce_rdyz
+
+6. read sync non-muxed
+adv_rd_off: t_avdp_r
+oe_on: t_oeasu
+access: t_iaa, cyc_iaa, cyc_oe
+rd_cycle: t_cez_r, t_oez, t_ce_rdyz
+
+7. write async muxed
+adv_wr_off: t_avdp_w
+we_on, wr_data_mux_bus: t_weasu, t_aavdh, cyc_aavhd_we
+we_off: t_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_wr_cycle
+
+8. write async non-muxed
+adv_wr_off: t_avdp_w
+we_on, wr_data_mux_bus: t_weasu
+we_off: t_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_wr_cycle
+
+9. write sync muxed
+adv_wr_off: t_avdp_w, t_avdh
+we_on, wr_data_mux_bus: t_weasu, t_rdyo, t_aavdh, cyc_aavhd_we
+we_off: t_wpl, cyc_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_ce_rdyz
+
+10. write sync non-muxed
+adv_wr_off: t_avdp_w
+we_on, wr_data_mux_bus: t_weasu, t_rdyo
+we_off: t_wpl, cyc_wpl
+cs_wr_off: t_wph
+wr_cycle: t_cez_w, t_ce_rdyz
+
+
+Note: Many of gpmc timings are dependent on other gpmc timings (a few
+gpmc timings purely dependent on other gpmc timings, a reason that
+some of the gpmc timings are missing above), and it will result in
+indirect dependency of peripheral timings to gpmc timings other than
+mentioned above, refer timing routine for more details. To know what
+these peripheral timings correspond to, please see explanations in
+struct gpmc_device_timings definition. And for gpmc timings refer
+IP details (link above).
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 285070e..4c203ce 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -233,6 +233,18 @@ unsigned int gpmc_round_ns_to_ticks(unsigned int time_ns)
 	return ticks * gpmc_get_fclk_period() / 1000;
 }
 
+static unsigned int gpmc_ticks_to_ps(unsigned int ticks)
+{
+	return ticks * gpmc_get_fclk_period();
+}
+
+static unsigned int gpmc_round_ps_to_ticks(unsigned int time_ps)
+{
+	unsigned long ticks = gpmc_ps_to_ticks(time_ps);
+
+	return ticks * gpmc_get_fclk_period();
+}
+
 static inline void gpmc_cs_modify_reg(int cs, int reg, u32 mask, bool value)
 {
 	u32 l;
@@ -792,6 +804,319 @@ static void __devinit gpmc_mem_init(void)
 	}
 }
 
+static u32 gpmc_round_ps_to_sync_clk(u32 time_ps, u32 sync_clk)
+{
+	u32 temp;
+	int div;
+
+	div = gpmc_calc_divider(sync_clk);
+	temp = gpmc_ps_to_ticks(time_ps);
+	temp = (temp + div - 1) / div;
+	return gpmc_ticks_to_ps(temp * div);
+}
+
+/* XXX: can the cycles be avoided ? */
+static int gpmc_calc_sync_read_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_rd_off */
+	temp = dev_t->t_avdp_r;
+	/* XXX: mux check required ? */
+	if (mux) {
+		/* XXX: t_avdp not to be required for sync, only added for tusb
+		 * this indirectly necessitates requirement of t_avdp_r and
+		 * t_avdp_w instead of having a single t_avdp
+		 */
+		temp = max_t(u32, temp,	gpmc_t->clk_activation + dev_t->t_avdh);
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	}
+	gpmc_t->adv_rd_off = gpmc_round_ps_to_ticks(temp);
+
+	/* oe_on */
+	temp = dev_t->t_oeasu; /* XXX: remove this ? */
+	if (mux) {
+		temp = max_t(u32, temp,	gpmc_t->clk_activation + dev_t->t_ach);
+		temp = max_t(u32, temp, gpmc_t->adv_rd_off +
+				gpmc_ticks_to_ps(dev_t->cyc_aavdh_oe));
+	}
+	gpmc_t->oe_on = gpmc_round_ps_to_ticks(temp);
+
+	/* access */
+	/* XXX: any scope for improvement ?, by combining oe_on
+	 * and clk_activation, need to check whether
+	 * access = clk_activation + round to sync clk ?
+	 */
+	temp = max_t(u32, dev_t->t_iaa,	dev_t->cyc_iaa * gpmc_t->sync_clk);
+	temp += gpmc_t->clk_activation;
+	if (dev_t->cyc_oe)
+		temp = max_t(u32, temp, gpmc_t->oe_on +
+				gpmc_ticks_to_ps(dev_t->cyc_oe));
+	gpmc_t->access = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->oe_off = gpmc_t->access + gpmc_ticks_to_ps(1);
+	gpmc_t->cs_rd_off = gpmc_t->oe_off;
+
+	/* rd_cycle */
+	temp = max_t(u32, dev_t->t_cez_r, dev_t->t_oez);
+	temp = gpmc_round_ps_to_sync_clk(temp, gpmc_t->sync_clk) +
+							gpmc_t->access;
+	/* XXX: barter t_ce_rdyz with t_cez_r ? */
+	if (dev_t->t_ce_rdyz)
+		temp = max_t(u32, temp,	gpmc_t->cs_rd_off + dev_t->t_ce_rdyz);
+	gpmc_t->rd_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_sync_write_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_wr_off */
+	temp = dev_t->t_avdp_w;
+	if (mux) {
+		temp = max_t(u32, temp,
+			gpmc_t->clk_activation + dev_t->t_avdh);
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	}
+	gpmc_t->adv_wr_off = gpmc_round_ps_to_ticks(temp);
+
+	/* wr_data_mux_bus */
+	temp = max_t(u32, dev_t->t_weasu,
+			gpmc_t->clk_activation + dev_t->t_rdyo);
+	/* XXX: shouldn't mux be kept as a whole for wr_data_mux_bus ?,
+	 * and in that case remember to handle we_on properly
+	 */
+	if (mux) {
+		temp = max_t(u32, temp,
+			gpmc_t->adv_wr_off + dev_t->t_aavdh);
+		temp = max_t(u32, temp, gpmc_t->adv_wr_off +
+				gpmc_ticks_to_ps(dev_t->cyc_aavdh_we));
+	}
+	gpmc_t->wr_data_mux_bus = gpmc_round_ps_to_ticks(temp);
+
+	/* we_on */
+	if (gpmc_capability & GPMC_HAS_WR_DATA_MUX_BUS)
+		gpmc_t->we_on = gpmc_round_ps_to_ticks(dev_t->t_weasu);
+	else
+		gpmc_t->we_on = gpmc_t->wr_data_mux_bus;
+
+	/* wr_access */
+	/* XXX: gpmc_capability check reqd ? , even if not, will not harm */
+	gpmc_t->wr_access = gpmc_t->access;
+
+	/* we_off */
+	temp = gpmc_t->we_on + dev_t->t_wpl;
+	temp = max_t(u32, temp,
+			gpmc_t->wr_access + gpmc_ticks_to_ps(1));
+	temp = max_t(u32, temp,
+		gpmc_t->we_on + gpmc_ticks_to_ps(dev_t->cyc_wpl));
+	gpmc_t->we_off = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->cs_wr_off = gpmc_round_ps_to_ticks(gpmc_t->we_off +
+							dev_t->t_wph);
+
+	/* wr_cycle */
+	temp = gpmc_round_ps_to_sync_clk(dev_t->t_cez_w, gpmc_t->sync_clk);
+	temp += gpmc_t->wr_access;
+	/* XXX: barter t_ce_rdyz with t_cez_w ? */
+	if (dev_t->t_ce_rdyz)
+		temp = max_t(u32, temp,
+				 gpmc_t->cs_wr_off + dev_t->t_ce_rdyz);
+	gpmc_t->wr_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_async_read_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_rd_off */
+	temp = dev_t->t_avdp_r;
+	if (mux)
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	gpmc_t->adv_rd_off = gpmc_round_ps_to_ticks(temp);
+
+	/* oe_on */
+	temp = dev_t->t_oeasu;
+	if (mux)
+		temp = max_t(u32, temp,
+			gpmc_t->adv_rd_off + dev_t->t_aavdh);
+	gpmc_t->oe_on = gpmc_round_ps_to_ticks(temp);
+
+	/* access */
+	temp = max_t(u32, dev_t->t_iaa, /* XXX: remove t_iaa in async ? */
+				gpmc_t->oe_on + dev_t->t_oe);
+	temp = max_t(u32, temp,
+				gpmc_t->cs_on + dev_t->t_ce);
+	temp = max_t(u32, temp,
+				gpmc_t->adv_on + dev_t->t_aa);
+	gpmc_t->access = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->oe_off = gpmc_t->access + gpmc_ticks_to_ps(1);
+	gpmc_t->cs_rd_off = gpmc_t->oe_off;
+
+	/* rd_cycle */
+	temp = max_t(u32, dev_t->t_rd_cycle,
+			gpmc_t->cs_rd_off + dev_t->t_cez_r);
+	temp = max_t(u32, temp, gpmc_t->oe_off + dev_t->t_oez);
+	gpmc_t->rd_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_async_write_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t)
+{
+	bool mux = dev_t->mux;
+	u32 temp;
+
+	/* adv_wr_off */
+	temp = dev_t->t_avdp_w;
+	if (mux)
+		temp = max_t(u32, gpmc_t->adv_on + gpmc_ticks_to_ps(1), temp);
+	gpmc_t->adv_wr_off = gpmc_round_ps_to_ticks(temp);
+
+	/* wr_data_mux_bus */
+	temp = dev_t->t_weasu;
+	if (mux) {
+		temp = max_t(u32, temp,	gpmc_t->adv_wr_off + dev_t->t_aavdh);
+		temp = max_t(u32, temp, gpmc_t->adv_wr_off +
+				gpmc_ticks_to_ps(dev_t->cyc_aavdh_we));
+	}
+	gpmc_t->wr_data_mux_bus = gpmc_round_ps_to_ticks(temp);
+
+	/* we_on */
+	if (gpmc_capability & GPMC_HAS_WR_DATA_MUX_BUS)
+		gpmc_t->we_on = gpmc_round_ps_to_ticks(dev_t->t_weasu);
+	else
+		gpmc_t->we_on = gpmc_t->wr_data_mux_bus;
+
+	/* we_off */
+	temp = gpmc_t->we_on + dev_t->t_wpl;
+	gpmc_t->we_off = gpmc_round_ps_to_ticks(temp);
+
+	gpmc_t->cs_wr_off = gpmc_round_ps_to_ticks(gpmc_t->we_off +
+							dev_t->t_wph);
+
+	/* wr_cycle */
+	temp = max_t(u32, dev_t->t_wr_cycle,
+				gpmc_t->cs_wr_off + dev_t->t_cez_w);
+	gpmc_t->wr_cycle = gpmc_round_ps_to_ticks(temp);
+
+	return 0;
+}
+
+static int gpmc_calc_sync_common_timings(struct gpmc_timings *gpmc_t,
+			struct gpmc_device_timings *dev_t)
+{
+	u32 temp;
+
+	gpmc_t->sync_clk = gpmc_calc_divider(dev_t->clk) *
+						gpmc_get_fclk_period();
+
+	gpmc_t->page_burst_access = gpmc_round_ps_to_sync_clk(
+					dev_t->t_bacc,
+					gpmc_t->sync_clk);
+
+	temp = max_t(u32, dev_t->t_ces, dev_t->t_avds);
+	gpmc_t->clk_activation = gpmc_round_ps_to_ticks(temp);
+
+	if (gpmc_calc_divider(gpmc_t->sync_clk) != 1)
+		return 0;
+
+	if (dev_t->ce_xdelay)
+		gpmc_t->bool_timings.cs_extra_delay = true;
+	if (dev_t->avd_xdelay)
+		gpmc_t->bool_timings.adv_extra_delay = true;
+	if (dev_t->oe_xdelay)
+		gpmc_t->bool_timings.oe_extra_delay = true;
+	if (dev_t->we_xdelay)
+		gpmc_t->bool_timings.we_extra_delay = true;
+
+	return 0;
+}
+
+static int gpmc_calc_common_timings(struct gpmc_timings *gpmc_t,
+			struct gpmc_device_timings *dev_t)
+{
+	u32 temp;
+
+	/* cs_on */
+	gpmc_t->cs_on = gpmc_round_ps_to_ticks(dev_t->t_ceasu);
+
+	/* adv_on */
+	temp = dev_t->t_avdasu;
+	if (dev_t->t_ce_avd)
+		temp = max_t(u32, temp,
+				gpmc_t->cs_on + dev_t->t_ce_avd);
+	gpmc_t->adv_on = gpmc_round_ps_to_ticks(temp);
+
+	if (dev_t->sync_write || dev_t->sync_read)
+		gpmc_calc_sync_common_timings(gpmc_t, dev_t);
+
+	return 0;
+}
+
+/* TODO: remove this function once all peripherals are confirmed to
+ * work with generic timing. Simultaneously gpmc_cs_set_timings()
+ * has to be modified to handle timings in ps instead of ns
+*/
+static void gpmc_convert_ps_to_ns(struct gpmc_timings *t)
+{
+	t->cs_on /= 1000;
+	t->cs_rd_off /= 1000;
+	t->cs_wr_off /= 1000;
+	t->adv_on /= 1000;
+	t->adv_rd_off /= 1000;
+	t->adv_wr_off /= 1000;
+	t->we_on /= 1000;
+	t->we_off /= 1000;
+	t->oe_on /= 1000;
+	t->oe_off /= 1000;
+	t->page_burst_access /= 1000;
+	t->access /= 1000;
+	t->rd_cycle /= 1000;
+	t->wr_cycle /= 1000;
+	t->bus_turnaround /= 1000;
+	t->cycle2cycle_delay /= 1000;
+	t->wait_monitoring /= 1000;
+	t->clk_activation /= 1000;
+	t->wr_access /= 1000;
+	t->wr_data_mux_bus /= 1000;
+}
+
+int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
+			struct gpmc_device_timings *dev_t)
+{
+	memset(gpmc_t, 0, sizeof(*gpmc_t));
+
+	gpmc_calc_common_timings(gpmc_t, dev_t);
+
+	if (dev_t->sync_read)
+		gpmc_calc_sync_read_timings(gpmc_t, dev_t);
+	else
+		gpmc_calc_async_read_timings(gpmc_t, dev_t);
+
+	if (dev_t->sync_write)
+		gpmc_calc_sync_write_timings(gpmc_t, dev_t);
+	else
+		gpmc_calc_async_write_timings(gpmc_t, dev_t);
+
+	/* TODO: remove, see function definition */
+	gpmc_convert_ps_to_ns(gpmc_t);
+
+	return 0;
+}
+
 static __devinit int gpmc_probe(struct platform_device *pdev)
 {
 	u32 l;
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h
index e08a51a..fe0a844 100644
--- a/arch/arm/mach-omap2/gpmc.h
+++ b/arch/arm/mach-omap2/gpmc.h
@@ -94,42 +94,104 @@ struct gpmc_timings {
 	u32 sync_clk;
 
 	/* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
-	u16 cs_on;		/* Assertion time */
-	u16 cs_rd_off;		/* Read deassertion time */
-	u16 cs_wr_off;		/* Write deassertion time */
+	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 */
-	u16 adv_on;		/* Assertion time */
-	u16 adv_rd_off;		/* Read deassertion time */
-	u16 adv_wr_off;		/* Write deassertion time */
+	u32 adv_on;		/* Assertion time */
+	u32 adv_rd_off;		/* Read deassertion time */
+	u32 adv_wr_off;		/* Write deassertion time */
 
 	/* WE signals timings corresponding to GPMC_CONFIG4 */
-	u16 we_on;		/* WE assertion time */
-	u16 we_off;		/* WE deassertion time */
+	u32 we_on;		/* WE assertion time */
+	u32 we_off;		/* WE deassertion time */
 
 	/* OE signals timings corresponding to GPMC_CONFIG4 */
-	u16 oe_on;		/* OE assertion time */
-	u16 oe_off;		/* OE deassertion time */
+	u32 oe_on;		/* OE assertion time */
+	u32 oe_off;		/* OE deassertion time */
 
 	/* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
-	u16 page_burst_access;	/* Multiple access word delay */
-	u16 access;		/* Start-cycle to first data valid delay */
-	u16 rd_cycle;		/* Total read cycle time */
-	u16 wr_cycle;		/* Total write cycle time */
+	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 */
 
-	u16 bus_turnaround;
-	u16 cycle2cycle_delay;
+	u32 bus_turnaround;
+	u32 cycle2cycle_delay;
 
-	u16 wait_monitoring;
-	u16 clk_activation;
+	u32 wait_monitoring;
+	u32 clk_activation;
 
 	/* The following are only on OMAP3430 */
-	u16 wr_access;		/* WRACCESSTIME */
-	u16 wr_data_mux_bus;	/* WRDATAONADMUXBUS */
+	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 */
+
+	bool mux;	/* address & data muxed */
+	bool sync_write;/* synchronous write */
+	bool sync_read;	/* synchronous read */
+
+	/* extra delays */
+	bool ce_xdelay;
+	bool avd_xdelay;
+	bool oe_xdelay;
+	bool we_xdelay;
+};
+
+extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
+				struct gpmc_device_timings *dev_t);
+
 extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
 extern int gpmc_get_client_irq(unsigned irq_config);
 
-- 
1.7.12

[PATCH 2/4] ARM: OMAP2+: onenand: generic timing calculation

[Afzal Mohammed]

Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/gpmc-onenand.c | 124 +++++++++++++------------------------
 1 file changed, 43 insertions(+), 81 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 54e2255..94a349e 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -49,6 +49,7 @@ static struct platform_device gpmc_onenand_device = {
 
 static struct gpmc_timings omap2_onenand_calc_async_timings(void)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings t;
 
 	const int t_cer = 15;
@@ -58,35 +59,24 @@ static struct gpmc_timings omap2_onenand_calc_async_timings(void)
 	const int t_aa = 76;
 	const int t_oe = 20;
 	const int t_cez = 20; /* max of t_cez, t_oez */
-	const int t_ds = 30;
 	const int t_wpl = 40;
 	const int t_wph = 30;
 
-	memset(&t, 0, sizeof(t));
-	t.sync_clk = 0;
-	t.cs_on = 0;
-	t.adv_on = 0;
-
-	/* Read */
-	t.adv_rd_off = gpmc_round_ns_to_ticks(max_t(int, t_avdp, t_cer));
-	t.oe_on  = t.adv_rd_off + gpmc_round_ns_to_ticks(t_aavdh);
-	t.access = t.adv_on + gpmc_round_ns_to_ticks(t_aa);
-	t.access = max_t(int, t.access, t.cs_on + gpmc_round_ns_to_ticks(t_ce));
-	t.access = max_t(int, t.access, t.oe_on + gpmc_round_ns_to_ticks(t_oe));
-	t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
-	t.cs_rd_off = t.oe_off;
-	t.rd_cycle  = t.cs_rd_off + gpmc_round_ns_to_ticks(t_cez);
-
-	/* Write */
-	t.adv_wr_off = t.adv_rd_off;
-	t.we_on  = t.oe_on;
-	if (cpu_is_omap34xx()) {
-		t.wr_data_mux_bus = t.we_on;
-		t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
-	}
-	t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
-	t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
-	t.wr_cycle  = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	dev_t.mux = true;
+	dev_t.t_avdp_r = max_t(int, t_avdp, t_cer) * 1000;
+	dev_t.t_avdp_w = dev_t.t_avdp_r;
+	dev_t.t_aavdh = t_aavdh * 1000;
+	dev_t.t_aa = t_aa * 1000;
+	dev_t.t_ce = t_ce * 1000;
+	dev_t.t_oe = t_oe * 1000;
+	dev_t.t_cez_r = t_cez * 1000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.t_wpl = t_wpl * 1000;
+	dev_t.t_wph = t_wph * 1000;
+
+	gpmc_calc_timings(&t, &dev_t);
 
 	return t;
 }
@@ -172,16 +162,15 @@ static struct gpmc_timings
 omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
 				int freq)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings t;
 	const int t_cer  = 15;
 	const int t_avdp = 12;
 	const int t_cez  = 20; /* max of t_cez, t_oez */
-	const int t_ds   = 30;
 	const int t_wpl  = 40;
 	const int t_wph  = 30;
 	int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
-	int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
-	int ticks_cez;
+	int div, gpmc_clk_ns;
 
 	if (cfg->flags & ONENAND_SYNC_READ)
 		onenand_flags = ONENAND_FLAG_SYNCREAD;
@@ -248,62 +237,35 @@ omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
 		latency = 4;
 
 	/* Set synchronous read timings */
-	memset(&t, 0, sizeof(t));
-
-	if (div == 1) {
-		t.bool_timings.cs_extra_delay = true;
-		t.bool_timings.adv_extra_delay = true;
-		t.bool_timings.oe_extra_delay = true;
-		t.bool_timings.we_extra_delay = true;
-	}
+	memset(&dev_t, 0, sizeof(dev_t));
 
-	t.sync_clk = min_gpmc_clk_period;
-	t.cs_on = 0;
-	t.adv_on = 0;
-	fclk_offset_ns = gpmc_round_ns_to_ticks(max_t(int, t_ces, t_avds));
-	fclk_offset = gpmc_ns_to_ticks(fclk_offset_ns);
-	t.page_burst_access = gpmc_clk_ns;
-
-	/* Read */
-	t.adv_rd_off = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_avdh));
-	t.oe_on = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_ach));
-	/* Force at least 1 clk between AVD High to OE Low */
-	if (t.oe_on <= t.adv_rd_off)
-		t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
-	t.access = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div);
-	t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
-	t.cs_rd_off = t.oe_off;
-	ticks_cez = ((gpmc_ns_to_ticks(t_cez) + div - 1) / div) * div;
-	t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
-		     ticks_cez);
-
-	t.clk_activation = fclk_offset_ns;
-
-	/* Write */
+	dev_t.mux = true;
+	dev_t.sync_read = true;
 	if (onenand_flags & ONENAND_FLAG_SYNCWRITE) {
-		t.adv_wr_off = t.adv_rd_off;
-		t.we_on  = 0;
-		t.we_off = t.cs_rd_off;
-		t.cs_wr_off = t.cs_rd_off;
-		t.wr_cycle  = t.rd_cycle;
-		if (cpu_is_omap34xx()) {
-			t.wr_data_mux_bus = gpmc_ticks_to_ns(fclk_offset +
-					gpmc_ps_to_ticks(min_gpmc_clk_period +
-					t_rdyo * 1000));
-			t.wr_access = t.access;
-		}
+		dev_t.sync_write = true;
 	} else {
-		t.adv_wr_off = gpmc_round_ns_to_ticks(max_t(int,
-							t_avdp, t_cer));
-		t.we_on  = t.adv_wr_off + gpmc_round_ns_to_ticks(t_aavdh);
-		t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
-		t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
-		t.wr_cycle  = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
-		if (cpu_is_omap34xx()) {
-			t.wr_data_mux_bus = t.we_on;
-			t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
-		}
+		dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
+		dev_t.t_wpl = t_wpl * 1000;
+		dev_t.t_wph = t_wph * 1000;
+		dev_t.t_aavdh = t_aavdh * 1000;
 	}
+	dev_t.ce_xdelay = true;
+	dev_t.avd_xdelay = true;
+	dev_t.oe_xdelay = true;
+	dev_t.we_xdelay = true;
+	dev_t.clk = min_gpmc_clk_period;
+	dev_t.t_bacc = dev_t.clk;
+	dev_t.t_ces = t_ces * 1000;
+	dev_t.t_avds = t_avds * 1000;
+	dev_t.t_avdh = t_avdh * 1000;
+	dev_t.t_ach = t_ach * 1000;
+	dev_t.cyc_iaa = (latency + 1);
+	dev_t.t_cez_r = t_cez * 1000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.cyc_aavdh_oe = 1;
+	dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
+
+	gpmc_calc_timings(&t, &dev_t);
 
 	return t;
 }
-- 
1.7.12

[PATCH 2/4] ARM: OMAP2+: onenand: generic timing calculation

[Afzal Mohammed]

Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/gpmc-onenand.c | 124 +++++++++++++------------------------
 1 file changed, 43 insertions(+), 81 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index 54e2255..94a349e 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -49,6 +49,7 @@ static struct platform_device gpmc_onenand_device = {
 
 static struct gpmc_timings omap2_onenand_calc_async_timings(void)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings t;
 
 	const int t_cer = 15;
@@ -58,35 +59,24 @@ static struct gpmc_timings omap2_onenand_calc_async_timings(void)
 	const int t_aa = 76;
 	const int t_oe = 20;
 	const int t_cez = 20; /* max of t_cez, t_oez */
-	const int t_ds = 30;
 	const int t_wpl = 40;
 	const int t_wph = 30;
 
-	memset(&t, 0, sizeof(t));
-	t.sync_clk = 0;
-	t.cs_on = 0;
-	t.adv_on = 0;
-
-	/* Read */
-	t.adv_rd_off = gpmc_round_ns_to_ticks(max_t(int, t_avdp, t_cer));
-	t.oe_on  = t.adv_rd_off + gpmc_round_ns_to_ticks(t_aavdh);
-	t.access = t.adv_on + gpmc_round_ns_to_ticks(t_aa);
-	t.access = max_t(int, t.access, t.cs_on + gpmc_round_ns_to_ticks(t_ce));
-	t.access = max_t(int, t.access, t.oe_on + gpmc_round_ns_to_ticks(t_oe));
-	t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
-	t.cs_rd_off = t.oe_off;
-	t.rd_cycle  = t.cs_rd_off + gpmc_round_ns_to_ticks(t_cez);
-
-	/* Write */
-	t.adv_wr_off = t.adv_rd_off;
-	t.we_on  = t.oe_on;
-	if (cpu_is_omap34xx()) {
-		t.wr_data_mux_bus = t.we_on;
-		t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
-	}
-	t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
-	t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
-	t.wr_cycle  = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	dev_t.mux = true;
+	dev_t.t_avdp_r = max_t(int, t_avdp, t_cer) * 1000;
+	dev_t.t_avdp_w = dev_t.t_avdp_r;
+	dev_t.t_aavdh = t_aavdh * 1000;
+	dev_t.t_aa = t_aa * 1000;
+	dev_t.t_ce = t_ce * 1000;
+	dev_t.t_oe = t_oe * 1000;
+	dev_t.t_cez_r = t_cez * 1000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.t_wpl = t_wpl * 1000;
+	dev_t.t_wph = t_wph * 1000;
+
+	gpmc_calc_timings(&t, &dev_t);
 
 	return t;
 }
@@ -172,16 +162,15 @@ static struct gpmc_timings
 omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
 				int freq)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings t;
 	const int t_cer  = 15;
 	const int t_avdp = 12;
 	const int t_cez  = 20; /* max of t_cez, t_oez */
-	const int t_ds   = 30;
 	const int t_wpl  = 40;
 	const int t_wph  = 30;
 	int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
-	int div, fclk_offset_ns, fclk_offset, gpmc_clk_ns;
-	int ticks_cez;
+	int div, gpmc_clk_ns;
 
 	if (cfg->flags & ONENAND_SYNC_READ)
 		onenand_flags = ONENAND_FLAG_SYNCREAD;
@@ -248,62 +237,35 @@ omap2_onenand_calc_sync_timings(struct omap_onenand_platform_data *cfg,
 		latency = 4;
 
 	/* Set synchronous read timings */
-	memset(&t, 0, sizeof(t));
-
-	if (div == 1) {
-		t.bool_timings.cs_extra_delay = true;
-		t.bool_timings.adv_extra_delay = true;
-		t.bool_timings.oe_extra_delay = true;
-		t.bool_timings.we_extra_delay = true;
-	}
+	memset(&dev_t, 0, sizeof(dev_t));
 
-	t.sync_clk = min_gpmc_clk_period;
-	t.cs_on = 0;
-	t.adv_on = 0;
-	fclk_offset_ns = gpmc_round_ns_to_ticks(max_t(int, t_ces, t_avds));
-	fclk_offset = gpmc_ns_to_ticks(fclk_offset_ns);
-	t.page_burst_access = gpmc_clk_ns;
-
-	/* Read */
-	t.adv_rd_off = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_avdh));
-	t.oe_on = gpmc_ticks_to_ns(fclk_offset + gpmc_ns_to_ticks(t_ach));
-	/* Force at least 1 clk between AVD High to OE Low */
-	if (t.oe_on <= t.adv_rd_off)
-		t.oe_on = t.adv_rd_off + gpmc_round_ns_to_ticks(1);
-	t.access = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div);
-	t.oe_off = t.access + gpmc_round_ns_to_ticks(1);
-	t.cs_rd_off = t.oe_off;
-	ticks_cez = ((gpmc_ns_to_ticks(t_cez) + div - 1) / div) * div;
-	t.rd_cycle = gpmc_ticks_to_ns(fclk_offset + (latency + 1) * div +
-		     ticks_cez);
-
-	t.clk_activation = fclk_offset_ns;
-
-	/* Write */
+	dev_t.mux = true;
+	dev_t.sync_read = true;
 	if (onenand_flags & ONENAND_FLAG_SYNCWRITE) {
-		t.adv_wr_off = t.adv_rd_off;
-		t.we_on  = 0;
-		t.we_off = t.cs_rd_off;
-		t.cs_wr_off = t.cs_rd_off;
-		t.wr_cycle  = t.rd_cycle;
-		if (cpu_is_omap34xx()) {
-			t.wr_data_mux_bus = gpmc_ticks_to_ns(fclk_offset +
-					gpmc_ps_to_ticks(min_gpmc_clk_period +
-					t_rdyo * 1000));
-			t.wr_access = t.access;
-		}
+		dev_t.sync_write = true;
 	} else {
-		t.adv_wr_off = gpmc_round_ns_to_ticks(max_t(int,
-							t_avdp, t_cer));
-		t.we_on  = t.adv_wr_off + gpmc_round_ns_to_ticks(t_aavdh);
-		t.we_off = t.we_on + gpmc_round_ns_to_ticks(t_wpl);
-		t.cs_wr_off = t.we_off + gpmc_round_ns_to_ticks(t_wph);
-		t.wr_cycle  = t.cs_wr_off + gpmc_round_ns_to_ticks(t_cez);
-		if (cpu_is_omap34xx()) {
-			t.wr_data_mux_bus = t.we_on;
-			t.wr_access = t.we_on + gpmc_round_ns_to_ticks(t_ds);
-		}
+		dev_t.t_avdp_w = max(t_avdp, t_cer) * 1000;
+		dev_t.t_wpl = t_wpl * 1000;
+		dev_t.t_wph = t_wph * 1000;
+		dev_t.t_aavdh = t_aavdh * 1000;
 	}
+	dev_t.ce_xdelay = true;
+	dev_t.avd_xdelay = true;
+	dev_t.oe_xdelay = true;
+	dev_t.we_xdelay = true;
+	dev_t.clk = min_gpmc_clk_period;
+	dev_t.t_bacc = dev_t.clk;
+	dev_t.t_ces = t_ces * 1000;
+	dev_t.t_avds = t_avds * 1000;
+	dev_t.t_avdh = t_avdh * 1000;
+	dev_t.t_ach = t_ach * 1000;
+	dev_t.cyc_iaa = (latency + 1);
+	dev_t.t_cez_r = t_cez * 1000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.cyc_aavdh_oe = 1;
+	dev_t.t_rdyo = t_rdyo * 1000 + min_gpmc_clk_period;
+
+	gpmc_calc_timings(&t, &dev_t);
 
 	return t;
 }
-- 
1.7.12

[PATCH 3/4] ARM: OMAP2+: smc91x: generic timing calculation

[Afzal Mohammed]

Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++++++++++++++++-----------------------
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c b/arch/arm/mach-omap2/gpmc-smc91x.c
index 6eed907..11d0b75 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -58,6 +58,7 @@ static struct platform_device gpmc_smc91x_device = {
 static int smc91c96_gpmc_retime(void)
 {
 	struct gpmc_timings t;
+	struct gpmc_device_timings dev_t;
 	const int t3 = 10;	/* Figure 12.2 read and 12.4 write */
 	const int t4_r = 20;	/* Figure 12.2 read */
 	const int t4_w = 5;	/* Figure 12.4 write */
@@ -68,32 +69,6 @@ static int smc91c96_gpmc_retime(void)
 	const int t20 = 185;	/* Figure 12.2 read and 12.4 write */
 	u32 l;
 
-	memset(&t, 0, sizeof(t));
-
-	/* Read timings */
-	t.cs_on = 0;
-	t.adv_on = t.cs_on;
-	t.oe_on = t.adv_on + t3;
-	t.access = t.oe_on + t5;
-	t.oe_off = t.access;
-	t.adv_rd_off = t.oe_off + max(t4_r, t6);
-	t.cs_rd_off = t.oe_off;
-	t.rd_cycle = t20 - t.oe_on;
-
-	/* Write timings */
-	t.we_on = t.adv_on + t3;
-
-	if (cpu_is_omap34xx() && (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)) {
-		t.wr_data_mux_bus = t.we_on;
-		t.we_off = t.wr_data_mux_bus + t7;
-	} else
-		t.we_off = t.we_on + t7;
-	if (cpu_is_omap34xx())
-		t.wr_access = t.we_off;
-	t.adv_wr_off = t.we_off + max(t4_w, t8);
-	t.cs_wr_off = t.we_off + t4_w;
-	t.wr_cycle = t20 - t.we_on;
-
 	l = GPMC_CONFIG1_DEVICESIZE_16;
 	if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
 		l |= GPMC_CONFIG1_MUXADDDATA;
@@ -115,6 +90,22 @@ static int smc91c96_gpmc_retime(void)
 	if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
 		return 0;
 
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	dev_t.t_oeasu = t3 * 1000;
+	dev_t.t_oe = t5 * 1000;
+	dev_t.t_cez_r = t4_r * 1000;
+	dev_t.t_oez = t6 * 1000;
+	dev_t.t_rd_cycle = (t20 - t3) * 1000;
+
+	dev_t.t_weasu = t3 * 1000;
+	dev_t.t_wpl = t7 * 1000;
+	dev_t.t_wph = t8 * 1000;
+	dev_t.t_cez_w = t4_w * 1000;
+	dev_t.t_wr_cycle = (t20 - t3) * 1000;
+
+	gpmc_calc_timings(&t, &dev_t);
+
 	return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
 }
 
-- 
1.7.12

[PATCH 3/4] ARM: OMAP2+: smc91x: generic timing calculation

[Afzal Mohammed]

Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++++++++++++++++-----------------------
 1 file changed, 17 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-smc91x.c b/arch/arm/mach-omap2/gpmc-smc91x.c
index 6eed907..11d0b75 100644
--- a/arch/arm/mach-omap2/gpmc-smc91x.c
+++ b/arch/arm/mach-omap2/gpmc-smc91x.c
@@ -58,6 +58,7 @@ static struct platform_device gpmc_smc91x_device = {
 static int smc91c96_gpmc_retime(void)
 {
 	struct gpmc_timings t;
+	struct gpmc_device_timings dev_t;
 	const int t3 = 10;	/* Figure 12.2 read and 12.4 write */
 	const int t4_r = 20;	/* Figure 12.2 read */
 	const int t4_w = 5;	/* Figure 12.4 write */
@@ -68,32 +69,6 @@ static int smc91c96_gpmc_retime(void)
 	const int t20 = 185;	/* Figure 12.2 read and 12.4 write */
 	u32 l;
 
-	memset(&t, 0, sizeof(t));
-
-	/* Read timings */
-	t.cs_on = 0;
-	t.adv_on = t.cs_on;
-	t.oe_on = t.adv_on + t3;
-	t.access = t.oe_on + t5;
-	t.oe_off = t.access;
-	t.adv_rd_off = t.oe_off + max(t4_r, t6);
-	t.cs_rd_off = t.oe_off;
-	t.rd_cycle = t20 - t.oe_on;
-
-	/* Write timings */
-	t.we_on = t.adv_on + t3;
-
-	if (cpu_is_omap34xx() && (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)) {
-		t.wr_data_mux_bus = t.we_on;
-		t.we_off = t.wr_data_mux_bus + t7;
-	} else
-		t.we_off = t.we_on + t7;
-	if (cpu_is_omap34xx())
-		t.wr_access = t.we_off;
-	t.adv_wr_off = t.we_off + max(t4_w, t8);
-	t.cs_wr_off = t.we_off + t4_w;
-	t.wr_cycle = t20 - t.we_on;
-
 	l = GPMC_CONFIG1_DEVICESIZE_16;
 	if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
 		l |= GPMC_CONFIG1_MUXADDDATA;
@@ -115,6 +90,22 @@ static int smc91c96_gpmc_retime(void)
 	if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
 		return 0;
 
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	dev_t.t_oeasu = t3 * 1000;
+	dev_t.t_oe = t5 * 1000;
+	dev_t.t_cez_r = t4_r * 1000;
+	dev_t.t_oez = t6 * 1000;
+	dev_t.t_rd_cycle = (t20 - t3) * 1000;
+
+	dev_t.t_weasu = t3 * 1000;
+	dev_t.t_wpl = t7 * 1000;
+	dev_t.t_wph = t8 * 1000;
+	dev_t.t_cez_w = t4_w * 1000;
+	dev_t.t_wr_cycle = (t20 - t3) * 1000;
+
+	gpmc_calc_timings(&t, &dev_t);
+
 	return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
 }
 
-- 
1.7.12

[PATCH 4/4] ARM: OMAP2+: tusb6010: generic timing calculation

[Afzal Mohammed]

Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/usb-tusb6010.c | 182 +++++++++----------------------------
 1 file changed, 44 insertions(+), 138 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c
index 8ee73fc..4c7d7b5 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -26,182 +26,88 @@ static u8		async_cs, sync_cs;
 static unsigned		refclk_psec;
 
 
-/* t2_ps, when quantized to fclk units, must happen no earlier than
- * the clock after after t1_NS.
- *
- * Return a possibly updated value of t2_ps, converted to nsec.
- */
-static unsigned
-next_clk(unsigned t1_NS, unsigned t2_ps, unsigned fclk_ps)
-{
-	unsigned	t1_ps = t1_NS * 1000;
-	unsigned	t1_f, t2_f;
-
-	if ((t1_ps + fclk_ps) < t2_ps)
-		return t2_ps / 1000;
-
-	t1_f = (t1_ps + fclk_ps - 1) / fclk_ps;
-	t2_f = (t2_ps + fclk_ps - 1) / fclk_ps;
-
-	if (t1_f >= t2_f)
-		t2_f = t1_f + 1;
-
-	return (t2_f * fclk_ps) / 1000;
-}
-
 /* NOTE:  timings are from tusb 6010 datasheet Rev 1.8, 12-Sept 2006 */
 
-static int tusb_set_async_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_async_mode(unsigned sysclk_ps)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings	t;
 	unsigned		t_acsnh_advnh = sysclk_ps + 3000;
-	unsigned		tmp;
-
-	memset(&t, 0, sizeof(t));
-
-	/* CS_ON = t_acsnh_acsnl */
-	t.cs_on = 8;
-	/* ADV_ON = t_acsnh_advnh - t_advn */
-	t.adv_on = next_clk(t.cs_on, t_acsnh_advnh - 7000, fclk_ps);
-
-	/*
-	 * READ ... from omap2420 TRM fig 12-13
-	 */
-
-	/* ADV_RD_OFF = t_acsnh_advnh */
-	t.adv_rd_off = next_clk(t.adv_on, t_acsnh_advnh, fclk_ps);
-
-	/* OE_ON = t_acsnh_advnh + t_advn_oen (then wait for nRDY) */
-	t.oe_on = next_clk(t.adv_on, t_acsnh_advnh + 1000, fclk_ps);
-
-	/* ACCESS = counters continue only after nRDY */
-	tmp = t.oe_on * 1000 + 300;
-	t.access = next_clk(t.oe_on, tmp, fclk_ps);
-
-	/* OE_OFF = after data gets sampled */
-	tmp = t.access * 1000;
-	t.oe_off = next_clk(t.access, tmp, fclk_ps);
-
-	t.cs_rd_off = t.oe_off;
-
-	tmp = t.cs_rd_off * 1000 + 7000 /* t_acsn_rdy_z */;
-	t.rd_cycle = next_clk(t.cs_rd_off, tmp, fclk_ps);
-
-	/*
-	 * WRITE ... from omap2420 TRM fig 12-15
-	 */
 
-	/* ADV_WR_OFF = t_acsnh_advnh */
-	t.adv_wr_off = t.adv_rd_off;
+	memset(&dev_t, 0, sizeof(dev_t));
 
-	/* WE_ON = t_acsnh_advnh + t_advn_wen (then wait for nRDY) */
-	t.we_on = next_clk(t.adv_wr_off, t_acsnh_advnh + 1000, fclk_ps);
+	dev_t.mux = true;
 
-	/* WE_OFF = after data gets sampled */
-	tmp = t.we_on * 1000 + 300;
-	t.we_off = next_clk(t.we_on, tmp, fclk_ps);
+	dev_t.t_ceasu = 8 * 1000;
+	dev_t.t_avdasu = t_acsnh_advnh - 7000;
+	dev_t.t_ce_avd = 1000;
+	dev_t.t_avdp_r = t_acsnh_advnh;
+	dev_t.t_oeasu = t_acsnh_advnh + 1000;
+	dev_t.t_oe = 300;
+	dev_t.t_cez_r = 7000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.t_avdp_w = t_acsnh_advnh;
+	dev_t.t_weasu = t_acsnh_advnh + 1000;
+	dev_t.t_wpl = 300;
+	dev_t.cyc_aavdh_we = 1;
 
-	t.cs_wr_off = t.we_off;
-
-	tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
-	t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
+	gpmc_calc_timings(&t, &dev_t);
 
 	return gpmc_cs_set_timings(async_cs, &t);
 }
 
-static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_sync_mode(unsigned sysclk_ps)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings	t;
 	unsigned		t_scsnh_advnh = sysclk_ps + 3000;
-	unsigned		tmp;
-
-	memset(&t, 0, sizeof(t));
-	t.cs_on = 8;
-
-	/* ADV_ON = t_acsnh_advnh - t_advn */
-	t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
-
-	/* GPMC_CLK rate = fclk rate / div */
-	t.sync_clk = 11100 /* 11.1 nsec */;
-	tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
-	if (tmp > 4)
-		return -ERANGE;
-	if (tmp == 0)
-		tmp = 1;
-	t.page_burst_access = (fclk_ps * tmp) / 1000;
-
-	/*
-	 * READ ... based on omap2420 TRM fig 12-19, 12-20
-	 */
-
-	/* ADV_RD_OFF = t_scsnh_advnh */
-	t.adv_rd_off = next_clk(t.adv_on, t_scsnh_advnh, fclk_ps);
-
-	/* OE_ON = t_scsnh_advnh + t_advn_oen * fclk_ps (then wait for nRDY) */
-	tmp = (t.adv_rd_off * 1000) + (3 * fclk_ps);
-	t.oe_on = next_clk(t.adv_on, tmp, fclk_ps);
-
-	/* ACCESS = number of clock cycles after t_adv_eon */
-	tmp = (t.oe_on * 1000) + (5 * fclk_ps);
-	t.access = next_clk(t.oe_on, tmp, fclk_ps);
-
-	/* OE_OFF = after data gets sampled */
-	tmp = (t.access * 1000) + (1 * fclk_ps);
-	t.oe_off = next_clk(t.access, tmp, fclk_ps);
 
-	t.cs_rd_off = t.oe_off;
-
-	tmp = t.cs_rd_off * 1000 + 7000 /* t_scsn_rdy_z */;
-	t.rd_cycle = next_clk(t.cs_rd_off, tmp, fclk_ps);
-
-	/*
-	 * WRITE ... based on omap2420 TRM fig 12-21
-	 */
-
-	/* ADV_WR_OFF = t_scsnh_advnh */
-	t.adv_wr_off = t.adv_rd_off;
-
-	/* WE_ON = t_scsnh_advnh + t_advn_wen * fclk_ps (then wait for nRDY) */
-	tmp = (t.adv_wr_off * 1000) + (3 * fclk_ps);
-	t.we_on = next_clk(t.adv_wr_off, tmp, fclk_ps);
-
-	/* WE_OFF = number of clock cycles after t_adv_wen */
-	tmp = (t.we_on * 1000) + (6 * fclk_ps);
-	t.we_off = next_clk(t.we_on, tmp, fclk_ps);
-
-	t.cs_wr_off = t.we_off;
-
-	tmp = t.cs_wr_off * 1000 + 7000 /* t_scsn_rdy_z */;
-	t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
-
-	t.clk_activation = gpmc_ticks_to_ns(1);
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	dev_t.mux = true;
+	dev_t.sync_read = true;
+	dev_t.sync_write = true;
+
+	dev_t.clk = 11100;
+	dev_t.t_bacc = 1000;
+	dev_t.t_ces = 1000;
+	dev_t.t_ceasu = 8 * 1000;
+	dev_t.t_avdasu = t_scsnh_advnh - 7000;
+	dev_t.t_ce_avd = 1000;
+	dev_t.t_avdp_r = t_scsnh_advnh;
+	dev_t.cyc_aavdh_oe = 3;
+	dev_t.cyc_oe = 5;
+	dev_t.t_ce_rdyz = 7000;
+	dev_t.t_avdp_w = t_scsnh_advnh;
+	dev_t.cyc_aavdh_we = 3;
+	dev_t.cyc_wpl = 6;
+	dev_t.t_ce_rdyz = 7000;
+
+	gpmc_calc_timings(&t, &dev_t);
 
 	return gpmc_cs_set_timings(sync_cs, &t);
 }
 
-extern unsigned long gpmc_get_fclk_period(void);
-
 /* tusb driver calls this when it changes the chip's clocking */
 int tusb6010_platform_retime(unsigned is_refclk)
 {
 	static const char	error[] =
 		KERN_ERR "tusb6010 %s retime error %d\n";
 
-	unsigned	fclk_ps = gpmc_get_fclk_period();
 	unsigned	sysclk_ps;
 	int		status;
 
-	if (!refclk_psec || fclk_ps == 0)
+	if (!refclk_psec)
 		return -ENODEV;
 
 	sysclk_ps = is_refclk ? refclk_psec : TUSB6010_OSCCLK_60;
 
-	status = tusb_set_async_mode(sysclk_ps, fclk_ps);
+	status = tusb_set_async_mode(sysclk_ps);
 	if (status < 0) {
 		printk(error, "async", status);
 		goto done;
 	}
-	status = tusb_set_sync_mode(sysclk_ps, fclk_ps);
+	status = tusb_set_sync_mode(sysclk_ps);
 	if (status < 0)
 		printk(error, "sync", status);
 done:
-- 
1.7.12

[PATCH 4/4] ARM: OMAP2+: tusb6010: generic timing calculation

[Afzal Mohammed]

Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/usb-tusb6010.c | 182 +++++++++----------------------------
 1 file changed, 44 insertions(+), 138 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-tusb6010.c b/arch/arm/mach-omap2/usb-tusb6010.c
index 8ee73fc..4c7d7b5 100644
--- a/arch/arm/mach-omap2/usb-tusb6010.c
+++ b/arch/arm/mach-omap2/usb-tusb6010.c
@@ -26,182 +26,88 @@ static u8		async_cs, sync_cs;
 static unsigned		refclk_psec;
 
 
-/* t2_ps, when quantized to fclk units, must happen no earlier than
- * the clock after after t1_NS.
- *
- * Return a possibly updated value of t2_ps, converted to nsec.
- */
-static unsigned
-next_clk(unsigned t1_NS, unsigned t2_ps, unsigned fclk_ps)
-{
-	unsigned	t1_ps = t1_NS * 1000;
-	unsigned	t1_f, t2_f;
-
-	if ((t1_ps + fclk_ps) < t2_ps)
-		return t2_ps / 1000;
-
-	t1_f = (t1_ps + fclk_ps - 1) / fclk_ps;
-	t2_f = (t2_ps + fclk_ps - 1) / fclk_ps;
-
-	if (t1_f >= t2_f)
-		t2_f = t1_f + 1;
-
-	return (t2_f * fclk_ps) / 1000;
-}
-
 /* NOTE:  timings are from tusb 6010 datasheet Rev 1.8, 12-Sept 2006 */
 
-static int tusb_set_async_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_async_mode(unsigned sysclk_ps)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings	t;
 	unsigned		t_acsnh_advnh = sysclk_ps + 3000;
-	unsigned		tmp;
-
-	memset(&t, 0, sizeof(t));
-
-	/* CS_ON = t_acsnh_acsnl */
-	t.cs_on = 8;
-	/* ADV_ON = t_acsnh_advnh - t_advn */
-	t.adv_on = next_clk(t.cs_on, t_acsnh_advnh - 7000, fclk_ps);
-
-	/*
-	 * READ ... from omap2420 TRM fig 12-13
-	 */
-
-	/* ADV_RD_OFF = t_acsnh_advnh */
-	t.adv_rd_off = next_clk(t.adv_on, t_acsnh_advnh, fclk_ps);
-
-	/* OE_ON = t_acsnh_advnh + t_advn_oen (then wait for nRDY) */
-	t.oe_on = next_clk(t.adv_on, t_acsnh_advnh + 1000, fclk_ps);
-
-	/* ACCESS = counters continue only after nRDY */
-	tmp = t.oe_on * 1000 + 300;
-	t.access = next_clk(t.oe_on, tmp, fclk_ps);
-
-	/* OE_OFF = after data gets sampled */
-	tmp = t.access * 1000;
-	t.oe_off = next_clk(t.access, tmp, fclk_ps);
-
-	t.cs_rd_off = t.oe_off;
-
-	tmp = t.cs_rd_off * 1000 + 7000 /* t_acsn_rdy_z */;
-	t.rd_cycle = next_clk(t.cs_rd_off, tmp, fclk_ps);
-
-	/*
-	 * WRITE ... from omap2420 TRM fig 12-15
-	 */
 
-	/* ADV_WR_OFF = t_acsnh_advnh */
-	t.adv_wr_off = t.adv_rd_off;
+	memset(&dev_t, 0, sizeof(dev_t));
 
-	/* WE_ON = t_acsnh_advnh + t_advn_wen (then wait for nRDY) */
-	t.we_on = next_clk(t.adv_wr_off, t_acsnh_advnh + 1000, fclk_ps);
+	dev_t.mux = true;
 
-	/* WE_OFF = after data gets sampled */
-	tmp = t.we_on * 1000 + 300;
-	t.we_off = next_clk(t.we_on, tmp, fclk_ps);
+	dev_t.t_ceasu = 8 * 1000;
+	dev_t.t_avdasu = t_acsnh_advnh - 7000;
+	dev_t.t_ce_avd = 1000;
+	dev_t.t_avdp_r = t_acsnh_advnh;
+	dev_t.t_oeasu = t_acsnh_advnh + 1000;
+	dev_t.t_oe = 300;
+	dev_t.t_cez_r = 7000;
+	dev_t.t_cez_w = dev_t.t_cez_r;
+	dev_t.t_avdp_w = t_acsnh_advnh;
+	dev_t.t_weasu = t_acsnh_advnh + 1000;
+	dev_t.t_wpl = 300;
+	dev_t.cyc_aavdh_we = 1;
 
-	t.cs_wr_off = t.we_off;
-
-	tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
-	t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
+	gpmc_calc_timings(&t, &dev_t);
 
 	return gpmc_cs_set_timings(async_cs, &t);
 }
 
-static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
+static int tusb_set_sync_mode(unsigned sysclk_ps)
 {
+	struct gpmc_device_timings dev_t;
 	struct gpmc_timings	t;
 	unsigned		t_scsnh_advnh = sysclk_ps + 3000;
-	unsigned		tmp;
-
-	memset(&t, 0, sizeof(t));
-	t.cs_on = 8;
-
-	/* ADV_ON = t_acsnh_advnh - t_advn */
-	t.adv_on = next_clk(t.cs_on, t_scsnh_advnh - 7000, fclk_ps);
-
-	/* GPMC_CLK rate = fclk rate / div */
-	t.sync_clk = 11100 /* 11.1 nsec */;
-	tmp = (t.sync_clk + fclk_ps - 1) / fclk_ps;
-	if (tmp > 4)
-		return -ERANGE;
-	if (tmp == 0)
-		tmp = 1;
-	t.page_burst_access = (fclk_ps * tmp) / 1000;
-
-	/*
-	 * READ ... based on omap2420 TRM fig 12-19, 12-20
-	 */
-
-	/* ADV_RD_OFF = t_scsnh_advnh */
-	t.adv_rd_off = next_clk(t.adv_on, t_scsnh_advnh, fclk_ps);
-
-	/* OE_ON = t_scsnh_advnh + t_advn_oen * fclk_ps (then wait for nRDY) */
-	tmp = (t.adv_rd_off * 1000) + (3 * fclk_ps);
-	t.oe_on = next_clk(t.adv_on, tmp, fclk_ps);
-
-	/* ACCESS = number of clock cycles after t_adv_eon */
-	tmp = (t.oe_on * 1000) + (5 * fclk_ps);
-	t.access = next_clk(t.oe_on, tmp, fclk_ps);
-
-	/* OE_OFF = after data gets sampled */
-	tmp = (t.access * 1000) + (1 * fclk_ps);
-	t.oe_off = next_clk(t.access, tmp, fclk_ps);
 
-	t.cs_rd_off = t.oe_off;
-
-	tmp = t.cs_rd_off * 1000 + 7000 /* t_scsn_rdy_z */;
-	t.rd_cycle = next_clk(t.cs_rd_off, tmp, fclk_ps);
-
-	/*
-	 * WRITE ... based on omap2420 TRM fig 12-21
-	 */
-
-	/* ADV_WR_OFF = t_scsnh_advnh */
-	t.adv_wr_off = t.adv_rd_off;
-
-	/* WE_ON = t_scsnh_advnh + t_advn_wen * fclk_ps (then wait for nRDY) */
-	tmp = (t.adv_wr_off * 1000) + (3 * fclk_ps);
-	t.we_on = next_clk(t.adv_wr_off, tmp, fclk_ps);
-
-	/* WE_OFF = number of clock cycles after t_adv_wen */
-	tmp = (t.we_on * 1000) + (6 * fclk_ps);
-	t.we_off = next_clk(t.we_on, tmp, fclk_ps);
-
-	t.cs_wr_off = t.we_off;
-
-	tmp = t.cs_wr_off * 1000 + 7000 /* t_scsn_rdy_z */;
-	t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
-
-	t.clk_activation = gpmc_ticks_to_ns(1);
+	memset(&dev_t, 0, sizeof(dev_t));
+
+	dev_t.mux = true;
+	dev_t.sync_read = true;
+	dev_t.sync_write = true;
+
+	dev_t.clk = 11100;
+	dev_t.t_bacc = 1000;
+	dev_t.t_ces = 1000;
+	dev_t.t_ceasu = 8 * 1000;
+	dev_t.t_avdasu = t_scsnh_advnh - 7000;
+	dev_t.t_ce_avd = 1000;
+	dev_t.t_avdp_r = t_scsnh_advnh;
+	dev_t.cyc_aavdh_oe = 3;
+	dev_t.cyc_oe = 5;
+	dev_t.t_ce_rdyz = 7000;
+	dev_t.t_avdp_w = t_scsnh_advnh;
+	dev_t.cyc_aavdh_we = 3;
+	dev_t.cyc_wpl = 6;
+	dev_t.t_ce_rdyz = 7000;
+
+	gpmc_calc_timings(&t, &dev_t);
 
 	return gpmc_cs_set_timings(sync_cs, &t);
 }
 
-extern unsigned long gpmc_get_fclk_period(void);
-
 /* tusb driver calls this when it changes the chip's clocking */
 int tusb6010_platform_retime(unsigned is_refclk)
 {
 	static const char	error[] =
 		KERN_ERR "tusb6010 %s retime error %d\n";
 
-	unsigned	fclk_ps = gpmc_get_fclk_period();
 	unsigned	sysclk_ps;
 	int		status;
 
-	if (!refclk_psec || fclk_ps == 0)
+	if (!refclk_psec)
 		return -ENODEV;
 
 	sysclk_ps = is_refclk ? refclk_psec : TUSB6010_OSCCLK_60;
 
-	status = tusb_set_async_mode(sysclk_ps, fclk_ps);
+	status = tusb_set_async_mode(sysclk_ps);
 	if (status < 0) {
 		printk(error, "async", status);
 		goto done;
 	}
-	status = tusb_set_sync_mode(sysclk_ps, fclk_ps);
+	status = tusb_set_sync_mode(sysclk_ps);
 	if (status < 0)
 		printk(error, "sync", status);
 done:
-- 
1.7.12

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Afzal Mohammed <afzal@ti.com> [121005 09:02]:
> 
> Proposed generic routine has been tested on OneNAND (async) on
> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
> local patch were used to test). For other cases of custom timing
> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
> calculation routine was verified by simulating on OMAP3EVM.

Have you tested to make sure this works if you change the
L3 frequency?

That should probably be tested as a sanity check. Maybe you
can force the L3 for some test boots for this, I don't think
we scale it by default.

Regards,

Tony

[PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Afzal Mohammed <afzal@ti.com> [121005 09:02]:
> 
> Proposed generic routine has been tested on OneNAND (async) on
> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
> local patch were used to test). For other cases of custom timing
> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
> calculation routine was verified by simulating on OMAP3EVM.

Have you tested to make sure this works if you change the
L3 frequency?

That should probably be tested as a sanity check. Maybe you
can force the L3 for some test boots for this, I don't think
we scale it by default.

Regards,

Tony

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Tony,

On Tuesday 09 October 2012 08:31 AM, Tony Lindgren wrote:
> * Afzal Mohammed<afzal@ti.com>  [121005 09:02]:

>> Proposed generic routine has been tested on OneNAND (async) on
>> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
>> local patch were used to test). For other cases of custom timing
>> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
>> calculation routine was verified by simulating on OMAP3EVM.
> Have you tested to make sure this works if you change the
> L3 frequency?

With changed L3 frequency it was not tested.

I do not have a single board that is supported in mainline that
calculates on the run gpmc timing from device timing. What has
been tested here is OneNAND working in asynchronous mode
on omap3evm, but it's support is not available in mainline, so
private patch had to be used to test it. All other peripherals
were tested by simulation, i.e. by comparing output from existing
custom timing routine & generic routine for particular frequencies.

> That should probably be tested as a sanity check. Maybe you
> can force the L3 for some test boots for this, I don't think
> we scale it by default.

On omap3evm, don't know whether L3 frequency can be
changed & still have a working Kernel. I am not sure whether
it is worth attempting as OneNAND on omap3evm is not
supported in mainline.

Regards
Afzal

[PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Tony,

On Tuesday 09 October 2012 08:31 AM, Tony Lindgren wrote:
> * Afzal Mohammed<afzal@ti.com>  [121005 09:02]:

>> Proposed generic routine has been tested on OneNAND (async) on
>> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
>> local patch were used to test). For other cases of custom timing
>> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
>> calculation routine was verified by simulating on OMAP3EVM.
> Have you tested to make sure this works if you change the
> L3 frequency?

With changed L3 frequency it was not tested.

I do not have a single board that is supported in mainline that
calculates on the run gpmc timing from device timing. What has
been tested here is OneNAND working in asynchronous mode
on omap3evm, but it's support is not available in mainline, so
private patch had to be used to test it. All other peripherals
were tested by simulation, i.e. by comparing output from existing
custom timing routine & generic routine for particular frequencies.

> That should probably be tested as a sanity check. Maybe you
> can force the L3 for some test boots for this, I don't think
> we scale it by default.

On omap3evm, don't know whether L3 frequency can be
changed & still have a working Kernel. I am not sure whether
it is worth attempting as OneNAND on omap3evm is not
supported in mainline.

Regards
Afzal

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Daniel Mack]

Hi,

On 05.10.2012 18:00, Afzal Mohammed wrote:
> This series provides a generic gpmc timing calculation routine. There
> were three peripherals (OneNAND, tusb6010, smc91x) using custom timing
> calculations, they are migrated to use the generic timing calculation.
> 
> Such a generic routine would help create a driver out of gpmc platform
> code, which would be peripheral agnostic and thus lead to DT finally.
> Input to generic timing calculation routine would be gpmc peripheral
> timings, output - translated timings that gpmc can understand. Later,
> to DT'ify, gpmc peripheral timings could be passed through DT. Input
> timings that has been used here are selected such that it represents
> those that are present in peripheral timing datasheets.

Admittedly, I lost track on the multiple GPMC series here, and they also
cause major merge conflicts with Linus' current master branch.

Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
would like to augment this to make GPMC attached NAND probable in DT, in
case this is still an open topic.


Thanks for you hard work,
Daniel




> This series has been created by pulling out last 4 patches in v7
> of the series,
> "OMAP-GPMC: generic time calc, prepare for driver"
> This was done to have easy path for common zImage gpmc cleanup patches.
> 
> Proposed generic routine has been tested on OneNAND (async) on
> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
> local patch were used to test). For other cases of custom timing
> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
> calculation routine was verified by simulating on OMAP3EVM.
> 
> This series is available
>         @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1
> and is based on
>         linux-next (next-20121005)
> and is dependent on
> 	http://marc.info/?l=linux-omap&m=134945131602622&w=2
> 	http://marc.info/?l=linux-omap&m=134945239306131&w=2
> 
> This series as such is only the first version, but these patches has
> already undergone one change before being made as this series. The
> change was in using ps instead of ns to prevent rounding errors.
> Also along with this series documentation has been improved.
> 
> Regards
> Afzal
> 
> 
> Afzal Mohammed (4):
>   ARM: OMAP2+: gpmc: generic timing calculation
>   ARM: OMAP2+: onenand: generic timing calculation
>   ARM: OMAP2+: smc91x: generic timing calculation
>   ARM: OMAP2+: tusb6010: generic timing calculation
> 
>  Documentation/bus-devices/ti-gpmc.txt | 122 +++++++++++++
>  arch/arm/mach-omap2/gpmc-onenand.c    | 124 +++++--------
>  arch/arm/mach-omap2/gpmc-smc91x.c     |  43 ++---
>  arch/arm/mach-omap2/gpmc.c            | 325 ++++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/gpmc.h            | 102 ++++++++---
>  arch/arm/mach-omap2/usb-tusb6010.c    | 182 +++++--------------
>  6 files changed, 633 insertions(+), 265 deletions(-)
>  create mode 100644 Documentation/bus-devices/ti-gpmc.txt
> 

[PATCH 0/4] OMAP-GPMC generic timing migration

[Daniel Mack]

Hi,

On 05.10.2012 18:00, Afzal Mohammed wrote:
> This series provides a generic gpmc timing calculation routine. There
> were three peripherals (OneNAND, tusb6010, smc91x) using custom timing
> calculations, they are migrated to use the generic timing calculation.
> 
> Such a generic routine would help create a driver out of gpmc platform
> code, which would be peripheral agnostic and thus lead to DT finally.
> Input to generic timing calculation routine would be gpmc peripheral
> timings, output - translated timings that gpmc can understand. Later,
> to DT'ify, gpmc peripheral timings could be passed through DT. Input
> timings that has been used here are selected such that it represents
> those that are present in peripheral timing datasheets.

Admittedly, I lost track on the multiple GPMC series here, and they also
cause major merge conflicts with Linus' current master branch.

Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
would like to augment this to make GPMC attached NAND probable in DT, in
case this is still an open topic.


Thanks for you hard work,
Daniel




> This series has been created by pulling out last 4 patches in v7
> of the series,
> "OMAP-GPMC: generic time calc, prepare for driver"
> This was done to have easy path for common zImage gpmc cleanup patches.
> 
> Proposed generic routine has been tested on OneNAND (async) on
> OMAP3EVM rev C (as mainline does not have the OneNAND support for this,
> local patch were used to test). For other cases of custom timing
> calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing
> calculation routine was verified by simulating on OMAP3EVM.
> 
> This series is available
>         @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1
> and is based on
>         linux-next (next-20121005)
> and is dependent on
> 	http://marc.info/?l=linux-omap&m=134945131602622&w=2
> 	http://marc.info/?l=linux-omap&m=134945239306131&w=2
> 
> This series as such is only the first version, but these patches has
> already undergone one change before being made as this series. The
> change was in using ps instead of ns to prevent rounding errors.
> Also along with this series documentation has been improved.
> 
> Regards
> Afzal
> 
> 
> Afzal Mohammed (4):
>   ARM: OMAP2+: gpmc: generic timing calculation
>   ARM: OMAP2+: onenand: generic timing calculation
>   ARM: OMAP2+: smc91x: generic timing calculation
>   ARM: OMAP2+: tusb6010: generic timing calculation
> 
>  Documentation/bus-devices/ti-gpmc.txt | 122 +++++++++++++
>  arch/arm/mach-omap2/gpmc-onenand.c    | 124 +++++--------
>  arch/arm/mach-omap2/gpmc-smc91x.c     |  43 ++---
>  arch/arm/mach-omap2/gpmc.c            | 325 ++++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/gpmc.h            | 102 ++++++++---
>  arch/arm/mach-omap2/usb-tusb6010.c    | 182 +++++--------------
>  6 files changed, 633 insertions(+), 265 deletions(-)
>  create mode 100644 Documentation/bus-devices/ti-gpmc.txt
> 

RE: [PATCH 0/4] OMAP-GPMC generic timing migration

[Mohammed, Afzal]

Hi Daniel,

On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote:

> Admittedly, I lost track on the multiple GPMC series here, and they also
> cause major merge conflicts with Linus' current master branch.
> 
> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I

Series [1-2] plus this series would be the required.
Note that 1st patch of series [2] has already reached mainline.

Another easy way would be, pull,
git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing

git checkout -b gpmc <myremote/gpmc-timing>
git rebase --onto <Linus-current-master> next-20121005 (or "080aa9c")

> would like to augment this to make GPMC attached NAND probable in DT, in
> case this is still an open topic.

I would be doing gpmc DT conversion next. Hoping that this
series too will be picked up by Tony, as once this series is
accepted, during DT conversion we need not rely on
auxdata (a last resort option) for timings.

> Thanks for you hard work,

Thanks, it was a pleasure to read the above.

Regards
Afzal

[1] http://marc.info/?l=linux-omap&m=134945131602622&w=2
[2] http://marc.info/?l=linux-omap&m=134967458329531&w=2

[PATCH 0/4] OMAP-GPMC generic timing migration

[Mohammed, Afzal]

Hi Daniel,

On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote:

> Admittedly, I lost track on the multiple GPMC series here, and they also
> cause major merge conflicts with Linus' current master branch.
> 
> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I

Series [1-2] plus this series would be the required.
Note that 1st patch of series [2] has already reached mainline.

Another easy way would be, pull,
git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing

git checkout -b gpmc <myremote/gpmc-timing>
git rebase --onto <Linus-current-master> next-20121005 (or "080aa9c")

> would like to augment this to make GPMC attached NAND probable in DT, in
> case this is still an open topic.

I would be doing gpmc DT conversion next. Hoping that this
series too will be picked up by Tony, as once this series is
accepted, during DT conversion we need not rely on
auxdata (a last resort option) for timings.

> Thanks for you hard work,

Thanks, it was a pleasure to read the above.

Regards
Afzal

[1] http://marc.info/?l=linux-omap&m=134945131602622&w=2
[2] http://marc.info/?l=linux-omap&m=134967458329531&w=2

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Mohammed, Afzal <afzal@ti.com> [121011 05:48]:
> Hi Daniel,
> 
> On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote:
> 
> > Admittedly, I lost track on the multiple GPMC series here, and they also
> > cause major merge conflicts with Linus' current master branch.
> > 
> > Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
> 
> Series [1-2] plus this series would be the required.
> Note that 1st patch of series [2] has already reached mainline.
> 
> Another easy way would be, pull,
> git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing
> 
> git checkout -b gpmc <myremote/gpmc-timing>
> git rebase --onto <Linus-current-master> next-20121005 (or "080aa9c")

After -rc1 is out, let's plan on adding the minimal
set required for removing plat and mach includes from
drivers into a clean-up branch. Afzal, can you maybe
do a pull request for that set against -rc1 when it's
out? Just the minimal set of patches.

> > would like to augment this to make GPMC attached NAND probable in DT, in
> > case this is still an open topic.
> 
> I would be doing gpmc DT conversion next. Hoping that this
> series too will be picked up by Tony, as once this series is
> accepted, during DT conversion we need not rely on
> auxdata (a last resort option) for timings.

Yes, then please do a second pull request for what's needed
to apply the minimal DT bindings. For the DT binding, let's
just leave out the timings for now as we can load those from
auxdata. Then the binding for the timings can be added
later on. So just the minimal binding using standard features
for the iorange and interrupt.

Thanks,

Tony 

[PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Mohammed, Afzal <afzal@ti.com> [121011 05:48]:
> Hi Daniel,
> 
> On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote:
> 
> > Admittedly, I lost track on the multiple GPMC series here, and they also
> > cause major merge conflicts with Linus' current master branch.
> > 
> > Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
> 
> Series [1-2] plus this series would be the required.
> Note that 1st patch of series [2] has already reached mainline.
> 
> Another easy way would be, pull,
> git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing
> 
> git checkout -b gpmc <myremote/gpmc-timing>
> git rebase --onto <Linus-current-master> next-20121005 (or "080aa9c")

After -rc1 is out, let's plan on adding the minimal
set required for removing plat and mach includes from
drivers into a clean-up branch. Afzal, can you maybe
do a pull request for that set against -rc1 when it's
out? Just the minimal set of patches.

> > would like to augment this to make GPMC attached NAND probable in DT, in
> > case this is still an open topic.
> 
> I would be doing gpmc DT conversion next. Hoping that this
> series too will be picked up by Tony, as once this series is
> accepted, during DT conversion we need not rely on
> auxdata (a last resort option) for timings.

Yes, then please do a second pull request for what's needed
to apply the minimal DT bindings. For the DT binding, let's
just leave out the timings for now as we can load those from
auxdata. Then the binding for the timings can be added
later on. So just the minimal binding using standard features
for the iorange and interrupt.

Thanks,

Tony 

RE: [PATCH 0/4] OMAP-GPMC generic timing migration

[Mohammed, Afzal]

Hi Tony,

On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:
> * Mohammed, Afzal <afzal@ti.com> [121011 05:48]:

> After -rc1 is out, let's plan on adding the minimal
> set required for removing plat and mach includes from
> drivers into a clean-up branch. Afzal, can you maybe
> do a pull request for that set against -rc1 when it's
> out? Just the minimal set of patches.

Pull request on gpmc cleanup for common ARM zImage has
been sent.

> Yes, then please do a second pull request for what's needed
> to apply the minimal DT bindings. For the DT binding, let's
> just leave out the timings for now as we can load those from
> auxdata. Then the binding for the timings can be added
> later on. So just the minimal binding using standard features
> for the iorange and interrupt.

Ok, I will keep timings aside for now and proceed with DT
(avoiding auxdata usage with generic routine looked to me a
saner approach though, with an initial DT'fy delay)

Regards
Afzal

[PATCH 0/4] OMAP-GPMC generic timing migration

[Mohammed, Afzal]

Hi Tony,

On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:
> * Mohammed, Afzal <afzal@ti.com> [121011 05:48]:

> After -rc1 is out, let's plan on adding the minimal
> set required for removing plat and mach includes from
> drivers into a clean-up branch. Afzal, can you maybe
> do a pull request for that set against -rc1 when it's
> out? Just the minimal set of patches.

Pull request on gpmc cleanup for common ARM zImage has
been sent.

> Yes, then please do a second pull request for what's needed
> to apply the minimal DT bindings. For the DT binding, let's
> just leave out the timings for now as we can load those from
> auxdata. Then the binding for the timings can be added
> later on. So just the minimal binding using standard features
> for the iorange and interrupt.

Ok, I will keep timings aside for now and proceed with DT
(avoiding auxdata usage with generic routine looked to me a
saner approach though, with an initial DT'fy delay)

Regards
Afzal

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Mohammed, Afzal <afzal@ti.com> [121015 05:42]:
> Hi Tony,
> 
> On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:
> > * Mohammed, Afzal <afzal@ti.com> [121011 05:48]:
> 
> > After -rc1 is out, let's plan on adding the minimal
> > set required for removing plat and mach includes from
> > drivers into a clean-up branch. Afzal, can you maybe
> > do a pull request for that set against -rc1 when it's
> > out? Just the minimal set of patches.
> 
> Pull request on gpmc cleanup for common ARM zImage has
> been sent.

Thanks.
 
> > Yes, then please do a second pull request for what's needed
> > to apply the minimal DT bindings. For the DT binding, let's
> > just leave out the timings for now as we can load those from
> > auxdata. Then the binding for the timings can be added
> > later on. So just the minimal binding using standard features
> > for the iorange and interrupt.
> 
> Ok, I will keep timings aside for now and proceed with DT
> (avoiding auxdata usage with generic routine looked to me a
> saner approach though, with an initial DT'fy delay)

Oh well if you think it's easier to do the timings too in
the DT binding, please go ahead with that. It may take some
longer discussion on the lists for the binding though. But
up to you.

Regards,

Tony

[PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Mohammed, Afzal <afzal@ti.com> [121015 05:42]:
> Hi Tony,
> 
> On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:
> > * Mohammed, Afzal <afzal@ti.com> [121011 05:48]:
> 
> > After -rc1 is out, let's plan on adding the minimal
> > set required for removing plat and mach includes from
> > drivers into a clean-up branch. Afzal, can you maybe
> > do a pull request for that set against -rc1 when it's
> > out? Just the minimal set of patches.
> 
> Pull request on gpmc cleanup for common ARM zImage has
> been sent.

Thanks.
 
> > Yes, then please do a second pull request for what's needed
> > to apply the minimal DT bindings. For the DT binding, let's
> > just leave out the timings for now as we can load those from
> > auxdata. Then the binding for the timings can be added
> > later on. So just the minimal binding using standard features
> > for the iorange and interrupt.
> 
> Ok, I will keep timings aside for now and proceed with DT
> (avoiding auxdata usage with generic routine looked to me a
> saner approach though, with an initial DT'fy delay)

Oh well if you think it's easier to do the timings too in
the DT binding, please go ahead with that. It may take some
longer discussion on the lists for the binding though. But
up to you.

Regards,

Tony

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Tony,

On Monday 15 October 2012 09:31 PM, Tony Lindgren wrote:
> * Mohammed, Afzal<afzal@ti.com>  [121015 05:42]:
>> On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:

>>> Yes, then please do a second pull request for what's needed
>>> to apply the minimal DT bindings. For the DT binding, let's
>>> just leave out the timings for now as we can load those from
>>> auxdata. Then the binding for the timings can be added
>>> later on. So just the minimal binding using standard features
>>> for the iorange and interrupt.

>> Ok, I will keep timings aside for now and proceed with DT
>> (avoiding auxdata usage with generic routine looked to me a
>> saner approach though, with an initial DT'fy delay)

> Oh well if you think it's easier to do the timings too in
> the DT binding, please go ahead with that. It may take some
> longer discussion on the lists for the binding though. But
> up to you.

I certainly don't think it is easier, rather tougher, cleaner
as well. One thing that worried me was, if we pursue the
auxdata path (a last resort option) and later if it is
objected, we would be back to square one.

Let me discuss internally and get back.

Regards
Afzal

[PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Tony,

On Monday 15 October 2012 09:31 PM, Tony Lindgren wrote:
> * Mohammed, Afzal<afzal@ti.com>  [121015 05:42]:
>> On Thu, Oct 11, 2012 at 20:17:56, Tony Lindgren wrote:

>>> Yes, then please do a second pull request for what's needed
>>> to apply the minimal DT bindings. For the DT binding, let's
>>> just leave out the timings for now as we can load those from
>>> auxdata. Then the binding for the timings can be added
>>> later on. So just the minimal binding using standard features
>>> for the iorange and interrupt.

>> Ok, I will keep timings aside for now and proceed with DT
>> (avoiding auxdata usage with generic routine looked to me a
>> saner approach though, with an initial DT'fy delay)

> Oh well if you think it's easier to do the timings too in
> the DT binding, please go ahead with that. It may take some
> longer discussion on the lists for the binding though. But
> up to you.

I certainly don't think it is easier, rather tougher, cleaner
as well. One thing that worried me was, if we pursue the
auxdata path (a last resort option) and later if it is
objected, we would be back to square one.

Let me discuss internally and get back.

Regards
Afzal

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Tony,

On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:

> I certainly don't think it is easier, rather tougher, cleaner
> as well. One thing that worried me was, if we pursue the
> auxdata path (a last resort option) and later if it is
> objected, we would be back to square one.

I commented on auxdata usage without visualising in more
detail how it can be implemented, it was bad of me.

I doubt whether auxdata would help here, it seems using
compatible field alone would help in deciding relevant
custom timing routine. Whether we want this kind of
peripheral knowledge in gpmc driver instead of using
generic timing routine has to be decided though.

> Let me discuss internally and get back.

Regards
Afzal

[PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Tony,

On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:

> I certainly don't think it is easier, rather tougher, cleaner
> as well. One thing that worried me was, if we pursue the
> auxdata path (a last resort option) and later if it is
> objected, we would be back to square one.

I commented on auxdata usage without visualising in more
detail how it can be implemented, it was bad of me.

I doubt whether auxdata would help here, it seems using
compatible field alone would help in deciding relevant
custom timing routine. Whether we want this kind of
peripheral knowledge in gpmc driver instead of using
generic timing routine has to be decided though.

> Let me discuss internally and get back.

Regards
Afzal

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Daniel Mack]

Hi Afzal,

On 17.10.2012 07:42, Afzal Mohammed wrote:
> On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
>> I certainly don't think it is easier, rather tougher, cleaner
>> as well. One thing that worried me was, if we pursue the
>> auxdata path (a last resort option) and later if it is
>> objected, we would be back to square one.
> 
> I commented on auxdata usage without visualising in more
> detail how it can be implemented, it was bad of me.
> 
> I doubt whether auxdata would help here, it seems using
> compatible field alone would help in deciding relevant
> custom timing routine. Whether we want this kind of
> peripheral knowledge in gpmc driver instead of using
> generic timing routine has to be decided though.

Maybe slightly off-topic, but still:

When GPMC is used for driving NAND chips that comply to CFI, the timings
could actually be derived from the connected peripheral as well. I
believe a slowest-possible-mode will have to be selected first for the
identication phase.

Another thing that might be worth thinking about is that apart from the
GPMC host controller and the peripherals, there could be other
components like level shifters or series resistors on the board that
limit the maximum speed of transactions. So in fact we might be better
off storing all that timing details in the DT, as they are in fact
highly application specific.


Daniel

[PATCH 0/4] OMAP-GPMC generic timing migration

[Daniel Mack]

Hi Afzal,

On 17.10.2012 07:42, Afzal Mohammed wrote:
> On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
>> I certainly don't think it is easier, rather tougher, cleaner
>> as well. One thing that worried me was, if we pursue the
>> auxdata path (a last resort option) and later if it is
>> objected, we would be back to square one.
> 
> I commented on auxdata usage without visualising in more
> detail how it can be implemented, it was bad of me.
> 
> I doubt whether auxdata would help here, it seems using
> compatible field alone would help in deciding relevant
> custom timing routine. Whether we want this kind of
> peripheral knowledge in gpmc driver instead of using
> generic timing routine has to be decided though.

Maybe slightly off-topic, but still:

When GPMC is used for driving NAND chips that comply to CFI, the timings
could actually be derived from the connected peripheral as well. I
believe a slowest-possible-mode will have to be selected first for the
identication phase.

Another thing that might be worth thinking about is that apart from the
GPMC host controller and the peripherals, there could be other
components like level shifters or series resistors on the board that
limit the maximum speed of transactions. So in fact we might be better
off storing all that timing details in the DT, as they are in fact
highly application specific.


Daniel

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Daniel Mack <zonque@gmail.com> [121017 08:15]:
> Hi Afzal,
> 
> On 17.10.2012 07:42, Afzal Mohammed wrote:
> > On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
> >> I certainly don't think it is easier, rather tougher, cleaner
> >> as well. One thing that worried me was, if we pursue the
> >> auxdata path (a last resort option) and later if it is
> >> objected, we would be back to square one.
> > 
> > I commented on auxdata usage without visualising in more
> > detail how it can be implemented, it was bad of me.
> > 
> > I doubt whether auxdata would help here, it seems using
> > compatible field alone would help in deciding relevant
> > custom timing routine. Whether we want this kind of
> > peripheral knowledge in gpmc driver instead of using
> > generic timing routine has to be decided though.
> 
> Maybe slightly off-topic, but still:
> 
> When GPMC is used for driving NAND chips that comply to CFI, the timings
> could actually be derived from the connected peripheral as well. I
> believe a slowest-possible-mode will have to be selected first for the
> identication phase.

I wish.. Just getting things working to the identification phase
requires quite a bit of configuration for the timings.
 
> Another thing that might be worth thinking about is that apart from the
> GPMC host controller and the peripherals, there could be other
> components like level shifters or series resistors on the board that
> limit the maximum speed of transactions. So in fact we might be better
> off storing all that timing details in the DT, as they are in fact
> highly application specific.

Yes and the level shifters affect timings too.

Regards,

Tony

[PATCH 0/4] OMAP-GPMC generic timing migration

[Tony Lindgren]

* Daniel Mack <zonque@gmail.com> [121017 08:15]:
> Hi Afzal,
> 
> On 17.10.2012 07:42, Afzal Mohammed wrote:
> > On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
> >> I certainly don't think it is easier, rather tougher, cleaner
> >> as well. One thing that worried me was, if we pursue the
> >> auxdata path (a last resort option) and later if it is
> >> objected, we would be back to square one.
> > 
> > I commented on auxdata usage without visualising in more
> > detail how it can be implemented, it was bad of me.
> > 
> > I doubt whether auxdata would help here, it seems using
> > compatible field alone would help in deciding relevant
> > custom timing routine. Whether we want this kind of
> > peripheral knowledge in gpmc driver instead of using
> > generic timing routine has to be decided though.
> 
> Maybe slightly off-topic, but still:
> 
> When GPMC is used for driving NAND chips that comply to CFI, the timings
> could actually be derived from the connected peripheral as well. I
> believe a slowest-possible-mode will have to be selected first for the
> identication phase.

I wish.. Just getting things working to the identification phase
requires quite a bit of configuration for the timings.
 
> Another thing that might be worth thinking about is that apart from the
> GPMC host controller and the peripherals, there could be other
> components like level shifters or series resistors on the board that
> limit the maximum speed of transactions. So in fact we might be better
> off storing all that timing details in the DT, as they are in fact
> highly application specific.

Yes and the level shifters affect timings too.

Regards,

Tony

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Daniel,

On Wednesday 17 October 2012 08:43 PM, Daniel Mack wrote:
> On 17.10.2012 07:42, Afzal Mohammed wrote:

>> I doubt whether auxdata would help here, it seems using
>> compatible field alone would help in deciding relevant
>> custom timing routine. Whether we want this kind of
>> peripheral knowledge in gpmc driver instead of using
>> generic timing routine has to be decided though.

> Another thing that might be worth thinking about is that apart from the
> GPMC host controller and the peripherals, there could be other
> components like level shifters or series resistors on the board that
> limit the maximum speed of transactions. So in fact we might be better
> off storing all that timing details in the DT, as they are in fact
> highly application specific.

Yes, making it future proof for these kind of scenarios was one
of the reason's that initially triggered generic timing path.

Regards
Afzal

[PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Daniel,

On Wednesday 17 October 2012 08:43 PM, Daniel Mack wrote:
> On 17.10.2012 07:42, Afzal Mohammed wrote:

>> I doubt whether auxdata would help here, it seems using
>> compatible field alone would help in deciding relevant
>> custom timing routine. Whether we want this kind of
>> peripheral knowledge in gpmc driver instead of using
>> generic timing routine has to be decided though.

> Another thing that might be worth thinking about is that apart from the
> GPMC host controller and the peripherals, there could be other
> components like level shifters or series resistors on the board that
> limit the maximum speed of transactions. So in fact we might be better
> off storing all that timing details in the DT, as they are in fact
> highly application specific.

Yes, making it future proof for these kind of scenarios was one
of the reason's that initially triggered generic timing path.

Regards
Afzal

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Daniel,

On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:

> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
> would like to augment this to make GPMC attached NAND probable in DT, in
> case this is still an open topic.

In case you can help on making gpmc nand dt probable, please
proceed. I would be on vacation next week, may be we can
discuss after I am back.

am335x based boards like beagle bone should be booting on
l-o master and it has gpmc header cleanup changes with
minimal driver support.

As I don't have the sufficient time to explain in detail, some
pointers. Discussion between us [1] hopefully explains it in brief.
It would be like peripherals connected to gpmc being represented
as child nodes in dt. gpmc driver probably in probe would have to
invoke of_platform_populate to create child nodes (for devices like
nand). And driver would have to be enhanced to configure gpmc
based on information passed through dt for each child nodes.
Or roughly have a dt equivalent of driver as in [2].

One issue would be the memory resource creation by gpmc
driver and which has to be provided to client resource data.
And a decision has to be taken whether a generic routine is
going to be used or initially a custom routine invocation
based on child compatible fields would be sufficient.

Regards
Afzal

[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74397.html
[2] git://gitorious.org/x0148406-public/linux-kernel tags/gpmc-drv-v6

[PATCH 0/4] OMAP-GPMC generic timing migration

[Afzal Mohammed]

Hi Daniel,

On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:

> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
> would like to augment this to make GPMC attached NAND probable in DT, in
> case this is still an open topic.

In case you can help on making gpmc nand dt probable, please
proceed. I would be on vacation next week, may be we can
discuss after I am back.

am335x based boards like beagle bone should be booting on
l-o master and it has gpmc header cleanup changes with
minimal driver support.

As I don't have the sufficient time to explain in detail, some
pointers. Discussion between us [1] hopefully explains it in brief.
It would be like peripherals connected to gpmc being represented
as child nodes in dt. gpmc driver probably in probe would have to
invoke of_platform_populate to create child nodes (for devices like
nand). And driver would have to be enhanced to configure gpmc
based on information passed through dt for each child nodes.
Or roughly have a dt equivalent of driver as in [2].

One issue would be the memory resource creation by gpmc
driver and which has to be provided to client resource data.
And a decision has to be taken whether a generic routine is
going to be used or initially a custom routine invocation
based on child compatible fields would be sufficient.

Regards
Afzal

[1] http://www.mail-archive.com/linux-omap at vger.kernel.org/msg74397.html
[2] git://gitorious.org/x0148406-public/linux-kernel tags/gpmc-drv-v6

Re: [PATCH 0/4] OMAP-GPMC generic timing migration

[Daniel Mack]

On 19.10.2012 17:34, Afzal Mohammed wrote:
> Hi Daniel,
> 
> On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:
> 
>> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
>> would like to augment this to make GPMC attached NAND probable in DT, in
>> case this is still an open topic.
> 
> In case you can help on making gpmc nand dt probable, please
> proceed. I would be on vacation next week, may be we can
> discuss after I am back.

Enjoy your vacation :)

> am335x based boards like beagle bone should be booting on
> l-o master and it has gpmc header cleanup changes with
> minimal driver support.
> 
> As I don't have the sufficient time to explain in detail, some
> pointers. Discussion between us [1] hopefully explains it in brief.
> It would be like peripherals connected to gpmc being represented
> as child nodes in dt. gpmc driver probably in probe would have to
> invoke of_platform_populate to create child nodes (for devices like
> nand). And driver would have to be enhanced to configure gpmc
> based on information passed through dt for each child nodes.
> Or roughly have a dt equivalent of driver as in [2].

Hmm, not sure if I follow all your thought here, but I cooked up
something that is straight-forward and works well for me. I'll post them
now, so we at least have a base for discussions ...


Daniel

[PATCH 0/4] OMAP-GPMC generic timing migration

[Daniel Mack]

On 19.10.2012 17:34, Afzal Mohammed wrote:
> Hi Daniel,
> 
> On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:
> 
>> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
>> would like to augment this to make GPMC attached NAND probable in DT, in
>> case this is still an open topic.
> 
> In case you can help on making gpmc nand dt probable, please
> proceed. I would be on vacation next week, may be we can
> discuss after I am back.

Enjoy your vacation :)

> am335x based boards like beagle bone should be booting on
> l-o master and it has gpmc header cleanup changes with
> minimal driver support.
> 
> As I don't have the sufficient time to explain in detail, some
> pointers. Discussion between us [1] hopefully explains it in brief.
> It would be like peripherals connected to gpmc being represented
> as child nodes in dt. gpmc driver probably in probe would have to
> invoke of_platform_populate to create child nodes (for devices like
> nand). And driver would have to be enhanced to configure gpmc
> based on information passed through dt for each child nodes.
> Or roughly have a dt equivalent of driver as in [2].

Hmm, not sure if I follow all your thought here, but I cooked up
something that is straight-forward and works well for me. I'll post them
now, so we at least have a base for discussions ...


Daniel