1. 14 7月, 2014 1 次提交
  2. 11 3月, 2014 3 次提交
  3. 29 9月, 2012 1 次提交
    • S
      mtd: cfi_cmdset_0001: Fix problem with unlocking timeout · 7be1f6b9
      Stefan Roese 提交于
      Unlocking may take up to 1.4 seconds on some Intel flashes. So
      lets use a max. of 1.5 seconds (1500ms) as timeout.
      
      See "Clear Block Lock-Bits Time" on page 40 in
      "3 Volt Intel StrataFlash Memory" 28F128J3,28F640J3,28F320J3 manual
      from February 2003
      
      This patch also fixes some other problems with this timeout:
      
      - Don't use HZ in timeout "calculation"!
        While testing we noticed that an unlocking timeout occured with
        HZ=1000 and didn't occur with HZ=300. This was because the
        timeout parameter was calculated differently depending on the
        HZ value. Now a fixed value of 1500ms is used.
      
      - The last parameter of WAIT_TIMEOUT (defined to
        inval_cache_and_wait_for_operation) has to be passed in
        micro-seconds. So multiply the ms value with 1000 and not 100
        to calculate this value.
      
      - Use variable name "mdelay" instead of misleading "udelay".
      Signed-off-by: NStefan Roese <sr@denx.de>
      Tested-by: NStephan Gatzka <stephan@gatzka.org>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      7be1f6b9
  4. 27 3月, 2012 7 次提交
  5. 24 3月, 2012 1 次提交
  6. 25 5月, 2011 2 次提交
  7. 31 3月, 2011 1 次提交
  8. 11 3月, 2011 2 次提交
  9. 06 1月, 2011 1 次提交
  10. 04 12月, 2010 1 次提交
  11. 26 10月, 2010 1 次提交
  12. 09 8月, 2010 1 次提交
  13. 06 8月, 2010 1 次提交
  14. 02 8月, 2010 1 次提交
  15. 10 5月, 2010 1 次提交
    • S
      mtd: fix a huge latency problem in the MTD CFI and LPDDR flash drivers. · c4e77376
      Stefani Seibold 提交于
      The use of a memcpy() during a spinlock operation will cause very long
      thread context switch delays if the flash chip bandwidth is low and the
      data to be copied large, because a spinlock will disable preemption.
      
      For example: A flash with 6,5 MB/s bandwidth will cause under ubifs,
      which request sometimes 128 KiB (the flash erase size), a preemption delay of
      20 milliseconds. High priority threads will not be served during this
      time, regardless whether this threads access the flash or not. This behavior
      breaks real time.
      
      The patch changes all the use of spin_lock operations for xxxx->mutex
      into mutex operations, which is exact what the name says and means.
      
      I have checked the code of the drivers and there is no use of atomic
      pathes like interrupt or timers. The mtdoops facility will also not be used
      by this drivers. So it is dave to replace the spin_lock against mutex.
      
      There is no performance regression since the mutex is normally not
      acquired.
      
      Changelog:
       06.03.2010 First release
       26.03.2010 Fix mutex[1] issue and tested it for compile failure
      Signed-off-by: NStefani Seibold <stefani@seibold.net>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      c4e77376
  16. 25 2月, 2010 1 次提交
  17. 30 11月, 2009 3 次提交
  18. 16 9月, 2009 1 次提交
  19. 06 6月, 2009 2 次提交
  20. 21 3月, 2009 1 次提交
  21. 10 12月, 2008 1 次提交
    • A
      [MTD] update internal API to support 64-bit device size · 69423d99
      Adrian Hunter 提交于
      MTD internal API presently uses 32-bit values to represent
      device size.  This patch updates them to 64-bits but leaves
      the external API unchanged.  Extending the external API
      is a separate issue for several reasons.  First, no one
      needs it at the moment.  Secondly, whether the implementation
      is done with IOCTLs, sysfs or both is still debated.  Thirdly
      external API changes require the internal API to be accepted
      first.
      
      Note that although the MTD API will be able to support 64-bit
      device sizes, existing drivers do not and are not required
      to do so, although NAND base has been updated.
      
      In general, changing from 32-bit to 64-bit values cause little
      or no changes to the majority of the code with the following
      exceptions:
          	- printk message formats
          	- division and modulus of 64-bit values
          	- NAND base support
      	- 32-bit local variables used by mtdpart and mtdconcat
      	- naughtily assuming one structure maps to another
      	in MEMERASE ioctl
      Signed-off-by: NAdrian Hunter <ext-adrian.hunter@nokia.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      69423d99
  22. 27 9月, 2008 1 次提交
  23. 06 8月, 2008 1 次提交
    • A
      [MTD] [NOR] cfi_cmdset_0001: Timeouts for erase, write and unlock operations · e93cafe4
      Anders Grafström 提交于
      Timeouts are currently given by the typical operation time times 8.
      It works in the general well-behaved case but not when an erase block is
      failing. For erase operations, it seems that a failing erase block will
      keep the device state machine in erasing state until the vendor
      specified maximum timeout period has passed. By this time the driver
      would have long since timed out, left erasing state and attempted
      further operations which all fail. This patch implements timeouts using
      values from the CFI Query structure when available.
      The patch also sets a longer timeout for locking operations. The current
      value used for locking/unlocking given by 1000000/HZ microseconds is too
      short for devices like J3 and J5 Strataflash which have a typical clear
      lock-bits time of 0.5 seconds.
      Signed-off-by: NAnders Grafström <grfstrm@users.sourceforge.net>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      e93cafe4
  24. 03 8月, 2008 1 次提交
  25. 25 7月, 2008 1 次提交
    • A
      [MTD] [NOR] Fix -ETIMEO errors in CFI driver · 998453fb
      Alexey Korolev 提交于
      Existing CFI driver has problems with excessive writes during erase.
      If CFI driver does many writes during one erase cycle we may face the
      messages with -ETIMEO error on erase operation.  It may cause the
      following data corruption and kernel panics.
      
      The reason of the issue is related to specifics of suspend operation:
      if we write to flash during erase, suspend operation will cost some time
      to erase procedure (for P30 it could be significant). In current version of
      cfi driver the problem of many suspends is partially workarounded by adding
      some time reserv to any operation (8xerase_time) but if we have many writes
      during one erase the problem appears.
      
      This patch detects the suspend and resets timer if suspend occured. It
      has been well verified on different chips. No problems were found.
      Could you please include the patch as it is simple and fixes bad issue.
      Signed-off-by: NAlexey Korolev <akorolev@infradead.org>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      998453fb
  26. 05 6月, 2008 1 次提交
  27. 14 5月, 2008 1 次提交