1. 21 11月, 2014 1 次提交
    • T
      ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header · e639cd5b
      Tony Lindgren 提交于
      We still need to support platform data for omap3 until it's booting
      in device tree only mode. So let's add platform_data/omap-gpmc.h for
      that, and a minimal linux/omap-gpmc.h for the save and restore used
      by the PM code.
      
      Let's also keep a minimal mach-omap2/gpmc.h still around to avoid
      churn on the board-*.c files. Once omap3 boots in device tree only
      mode, we can drop mach-omap2/gpmc.h and we can make the data
      structures in platform_data/omap-gpmc.h private to the GPMC driver.
      
      Note that we can now also remove gpmc-nand.h and gpmc-onenand.h.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      e639cd5b
  2. 02 4月, 2013 6 次提交
  3. 09 11月, 2012 2 次提交
    • A
      ARM: OMAP2+: gpmc: generic timing calculation · 246da26d
      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: NAfzal Mohammed <afzal@ti.com>
      246da26d
    • A
      ARM: OMAP2+: gpmc: handle additional timings · 559d94b0
      Afzal Mohammed 提交于
      Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
      clkactivationtime in gpmc_cs_set_timings(). This is done so
      that boards can configure these parameters of gpmc in Kernel
      instead of relying on bootloader. Also configure bool type
      timings like extradelay.
      
      This needed change to the existing users that were configuring
      clk activation time and extra delay by directly writing to
      registers. Thanks to Tony for making me aware of users of clk
      activation and being kind enough to test the modified one.
      Signed-off-by: NAfzal Mohammed <afzal@ti.com>
      559d94b0
  4. 15 10月, 2012 4 次提交
  5. 31 8月, 2012 2 次提交
  6. 14 5月, 2012 1 次提交
    • I
      ARM: OMAP3: gpmc: add BCH ecc api and modes · 8d602cf5
      Ivan Djelic 提交于
      This patch adds a simple BCH ecc computation api, similar to the
      existing Hamming ecc api. It is intended to be used by the MTD layer.
      It implements the following features:
      
      - support 4-bit and 8-bit ecc computation
      - do not protect user bytes in spare area, only data area is protected
      - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs
      
      This last feature is obtained by adding a constant polynomial to
      the hardware computed ecc. It allows to correct bitflips in blank pages
      and is extremely useful to support filesystems such as UBIFS, which expect
      erased pages to contain only 0xFFs.
      
      This api has been tested on an OMAP3630 board.
      
      Artem: The OMAP maintainer Tony Lindgren gave us his blessing for merging
      this patch via the MTD tree.
      Signed-off-by: NIvan Djelic <ivan.djelic@parrot.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      8d602cf5
  7. 31 3月, 2011 1 次提交
  8. 18 2月, 2011 4 次提交
  9. 22 12月, 2010 1 次提交
  10. 02 8月, 2010 2 次提交
  11. 16 2月, 2010 2 次提交
    • V
      omap3: SDP: Introducing 'board-sdp-flash.c' for flash init · c2798e93
      Vimal Singh 提交于
      This patch adds 'board-sdp-flash.c', which could be utilized
      by boards similar to 3430SDP. (For ex: 2430sdp, 36030sdp).
      
      This file does initialization for all three flash devices present
      in SDP boards (NOR, NAND, OneNAND), by finding there 'cs' number
      dynamically using switch setting information (S8: 1-4).
      This also expects partition information from core board files (for
      ex: board-3430sdp.c). Which allows to choose different default
      partitions for different boards.
      
      A new structure is created for this purpose: 'flash_partitions'
      in 'mach/board-sdp.h'. This has two members:
      1. struct mtd_partition *parts
      2. int nr_parts
      
      A board file is expected to fill this structure and pass it to
      'sdp-flsash-init'. Partition information should be passed in
      structure array of 'flash_partitions'. Partition information should
      be passed in below sequence in array:
      NOR
      OneNAND
      NAND
      Signed-off-by: NVimal Singh <vimalsingh@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      c2798e93
    • F
      omap2/3/4: gpmc: avoid section definitions on headers · 2586ef0d
      Felipe Balbi 提交于
      trivial patch, no functional changes.
      Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      2586ef0d
  12. 12 12月, 2009 1 次提交
  13. 12 11月, 2009 1 次提交
  14. 21 10月, 2009 1 次提交
    • T
      omap: headers: Move remaining headers from include/mach to include/plat · ce491cf8
      Tony Lindgren 提交于
      Move the remaining headers under plat-omap/include/mach
      to plat-omap/include/plat. Also search and replace the
      files using these headers to include using the right path.
      
      This was done with:
      
      #!/bin/bash
      mach_dir_old="arch/arm/plat-omap/include/mach"
      plat_dir_new="arch/arm/plat-omap/include/plat"
      headers=$(cd $mach_dir_old && ls *.h)
      omap_dirs="arch/arm/*omap*/ \
      drivers/video/omap \
      sound/soc/omap"
      other_files="drivers/leds/leds-ams-delta.c \
      drivers/mfd/menelaus.c \
      drivers/mfd/twl4030-core.c \
      drivers/mtd/nand/ams-delta.c"
      
      for header in $headers; do
      	old="#include <mach\/$header"
      	new="#include <plat\/$header"
      	for dir in $omap_dirs; do
      		find $dir -type f -name \*.[chS] | \
      			xargs sed -i "s/$old/$new/"
      	done
      	find drivers/ -type f -name \*omap*.[chS] | \
      		xargs sed -i "s/$old/$new/"
      	for file in $other_files; do
      		sed -i "s/$old/$new/" $file
      	done
      done
      
      for header in $(ls $mach_dir_old/*.h); do
      	git mv $header $plat_dir_new/
      done
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      ce491cf8
  15. 20 9月, 2009 1 次提交
  16. 09 2月, 2009 1 次提交
  17. 09 10月, 2008 1 次提交
    • S
      ARM: OMAP3: Add minimal omap3430 support · cc26b3b0
      Syed Mohammed, Khasim 提交于
      Add minimal omap3430 support based on earlier patches from
      Syed Mohammed Khasim. Also merge in omap34xx SRAM support
      from Karthik Dasu and use consistent naming for sram init
      functions.
      
      Also do following changes that make 34xx support usable:
      
      - Remove unused sram.c functions for 34xx
      
      - Rename IRQ_SIR_IRQ to INTCPS_SIR_IRQ and define it locally
        in entry-macro.S
      
      - Update mach-omap2/io.c to support 2420, 2430, and 34xx
      
      - Also merge in 34xx GPMC changes to add fields wr_access and
        wr_data_mux_bus from Adrian Hunter
      
      - Remove memory initialization call omap2_init_memory() until
        until more generic memory initialization patches are posted.
        It's OK to rely on bootloader initialization until then.
      Signed-off-by: NSyed Mohammed, Khasim <khasim@ti.com>
      Signed-off-by: Karthik Dasu<karthik-dp@ti.com>
      Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      
      
      
      cc26b3b0
  18. 06 10月, 2008 2 次提交
  19. 07 8月, 2008 1 次提交
  20. 21 9月, 2007 2 次提交
  21. 09 5月, 2007 2 次提交
  22. 25 9月, 2006 1 次提交