• Afzal Mohammed's avatar
    ARM: OMAP2+: gpmc: generic timing calculation · 246da26d
    Afzal Mohammed authored
    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
    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: default avatarAfzal Mohammed <afzal@ti.com>
Last commit
Last update
ti-gpmc.txt Loading commit data...