Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 3月, 2011 1 次提交
  3. 06 1月, 2011 1 次提交
  5. 04 12月, 2010 1 次提交
  7. 26 10月, 2010 1 次提交
  9. 09 8月, 2010 1 次提交
  11. 06 8月, 2010 1 次提交
  13. 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
  17. 25 2月, 2010 1 次提交
  19. 30 11月, 2009 3 次提交
  21. 16 9月, 2009 1 次提交
  23. 06 6月, 2009 2 次提交
  25. 21 3月, 2009 1 次提交
  27. 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
  29. 27 9月, 2008 1 次提交
  31. 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
  33. 03 8月, 2008 1 次提交
  35. 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
  37. 05 6月, 2008 1 次提交
  39. 14 5月, 2008 1 次提交
  41. 06 5月, 2008 1 次提交
  43. 02 5月, 2008 1 次提交
  45. 23 4月, 2008 2 次提交
  47. 22 4月, 2008 1 次提交
  49. 05 4月, 2008 1 次提交
  51. 03 2月, 2008 1 次提交
  53. 12 1月, 2008 1 次提交
  55. 26 11月, 2007 1 次提交
    • A
      [MTD] [NOR] Prevent erase command invocation on suspended chip · 6c24e416
      由 Alexander Belyakov 提交于 
      while running stress tests we have met cfi_cmdset_0001.c driver issue.
Working on multipartitional devices with erase suspend on write
feature enabled it is possible to get erase operation invoked on chip
with suspended erase. get_chip() looses information about earlier
suspended erase and new erase operation gets issued. New erase
operations report successful completion, but blocks remain dirty
causing, for example, JFFS2 error messages like:

...
Newly-erased block contained word 0x20031985 at offset 0x00200000
Newly-erased block contained word 0x20031985 at offset 0x00280000
Newly-erased block contained word 0x20031985 at offset 0x00240000
...

The patch below fixes that issue.
Signed-off-by: NAlexander Belyakov <alexander.belyakov@intel.com>
Acked-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      6c24e416
  57. 23 11月, 2007 1 次提交
  59. 31 10月, 2007 1 次提交
  61. 23 10月, 2007 1 次提交
  63. 13 10月, 2007 1 次提交
  65. 24 9月, 2007 1 次提交
  67. 05 7月, 2007 1 次提交
  69. 29 6月, 2007 2 次提交