OMAP-GPMC generic timing migration
Subsystems (7)
cover OMAP-GPMC generic timing migration
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=2This 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
Signature · 1 line
1.7.12
PATCH 1/4 ARM: OMAP2+: gpmc: generic timing calculation
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.
--- 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
Documentation/bus-devices/ti-gpmc.txt new file +122 -0
@@ -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).
arch/arm/mach-omap2/gpmc.c +325 -0
337 lines not on this page · raw message
arch/arm/mach-omap2/gpmc.h +82 -20
124 lines not on this page · raw message
Signature · 1 line
1.7.12
PATCH 2/4 ARM: OMAP2+: onenand: generic timing calculation
In reply to Afzal MohammedGeneric gpmc timing calculation helper is available now, use it instead of custom timing calculation.
--- arch/arm/mach-omap2/gpmc-onenand.c | 124 +++++++++++++------------------------ 1 file changed, 43 insertions(+), 81 deletions(-)
arch/arm/mach-omap2/gpmc-onenand.c +43 -81
@@ -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; }
Signature · 1 line
1.7.12
PATCH 3/4 ARM: OMAP2+: smc91x: generic timing calculation
In reply to Afzal MohammedGeneric gpmc timing calculation helper is available now, use it instead of custom timing calculation.
--- arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++++++++++++++++----------------------- 1 file changed, 17 insertions(+), 26 deletions(-)
arch/arm/mach-omap2/gpmc-smc91x.c +17 -26
@@ -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); }
Signature · 1 line
1.7.12
PATCH 4/4 ARM: OMAP2+: tusb6010: generic timing calculation
In reply to Afzal MohammedGeneric gpmc timing calculation helper is available now, use it instead of custom timing calculation.
--- arch/arm/mach-omap2/usb-tusb6010.c | 182 +++++++++---------------------------- 1 file changed, 44 insertions(+), 138 deletions(-)
arch/arm/mach-omap2/usb-tusb6010.c +44 -138
@@ -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:
Signature · 1 line
1.7.12
Tony Lindgren
maintainercover OMAP-GPMC generic timing migration
In reply to Afzal MohammedQuoted 6 lines · Afzal Mohammed
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
cover OMAP-GPMC generic timing migration
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 5 lines · Afzal Mohammed
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.
Quoted 3 lines
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
cover OMAP-GPMC generic timing migration
In reply to Afzal MohammedHi,
Quoted 11 lines · Afzal Mohammed
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
Quoted 43 lines
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=2This 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
AfzalAfzal 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 calculationDocumentation/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
cover OMAP-GPMC generic timing migration
Hi Daniel,
Quoted 4 lines · Daniel Mack
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")
Quoted 2 lines
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.
Quoted 1 line
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
Tony Lindgren
maintainercover OMAP-GPMC generic timing migration
Quoted 9 lines · Mohammed, Afzal
Hi Daniel,
Quoted 4 lines · Daniel Mack
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
Quoted 8 lines
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.gitgpmc-timinggit 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.
Quoted 7 lines
Quoted 2 lines
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
cover OMAP-GPMC generic timing migration
Hi Tony,
Quoted 7 lines · Tony Lindgren
* Mohammed, Afzal <[email protected]> [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.
Quoted 6 lines
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
Tony Lindgren
maintainercover OMAP-GPMC generic timing migration
Quoted 5 lines · Mohammed, Afzal
Hi Tony,
Quoted 1 line · Tony Lindgren
* Mohammed, Afzal <[email protected]> [121011 05:48]:
Quoted 8 lines
Quoted 5 lines
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.
Quoted 10 lines
Quoted 6 lines
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
cover OMAP-GPMC generic timing migration
Hi Tony,
Quoted 10 lines · Tony Lindgren
Quoted 8 lines · Mohammed, Afzal
Quoted 6 lines · Tony Lindgren
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.
Quoted 8 lines
Quoted 3 lines
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
cover OMAP-GPMC generic timing migration
Hi Tony,
Quoted 4 lines · Afzal Mohammed
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.
Quoted 1 line
Let me discuss internally and get back.
Regards
Afzal
cover OMAP-GPMC generic timing migration
Hi Afzal,
Quoted 6 lines · Afzal Mohammed
Quoted 4 lines · Afzal Mohammed
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.
Quoted 8 lines
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
Tony Lindgren
maintainercover OMAP-GPMC generic timing migration
Quoted 18 lines · Daniel Mack
Hi Afzal,
Quoted 6 lines · Afzal Mohammed
Quoted 4 lines · Afzal Mohammed
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.
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
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
cover OMAP-GPMC generic timing migration
In reply to Daniel MackHi Daniel,
Quoted 8 lines · Daniel Mack
Quoted 5 lines · Afzal Mohammed
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.
Quoted 6 lines
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
cover OMAP-GPMC generic timing migration
In reply to Daniel MackHi Daniel,
Quoted 3 lines · Daniel Mack
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
cover OMAP-GPMC generic timing migration
Quoted 11 lines · Afzal Mohammed
Hi Daniel,
Quoted 3 lines · Daniel Mack
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 :)
Quoted 4 lines
am335x based boards like beagle bone should be booting on l-o master and it has gpmc header cleanup changes with minimal driver support.
Quoted 8 lines
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_populateto 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