1. 09 Nov, 2012 1 commit
    • 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>