diff options
author | Afzal Mohammed <afzal@ti.com> | 2012-08-02 18:32:10 +0400 |
---|---|---|
committer | Afzal Mohammed <afzal@ti.com> | 2012-11-09 16:37:11 +0400 |
commit | 246da26d37311cd1b1489575f305042dcdecfd50 (patch) | |
tree | eefb42b4e84cdc1ee8b0f984eba17aca8ba036ce /arch/arm/mach-omap2/gpmc.h | |
parent | 559d94b00c4dca74b060bae1feeb81cac38628a6 (diff) | |
download | linux-246da26d37311cd1b1489575f305042dcdecfd50.tar.xz |
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.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Diffstat (limited to 'arch/arm/mach-omap2/gpmc.h')
-rw-r--r-- | arch/arm/mach-omap2/gpmc.h | 102 |
1 files changed, 82 insertions, 20 deletions
diff --git a/arch/arm/mach-omap2/gpmc.h b/arch/arm/mach-omap2/gpmc.h index e08a51a7a76a..fe0a844d5007 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); |