Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 03 2月, 2008 1 次提交
  3. 11 1月, 2008 1 次提交
  5. 03 12月, 2007 3 次提交
  7. 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
  9. 23 11月, 2007 1 次提交
  11. 10 11月, 2007 1 次提交
  13. 31 10月, 2007 1 次提交
  15. 23 10月, 2007 1 次提交
  17. 13 10月, 2007 1 次提交
  19. 24 9月, 2007 1 次提交
  21. 23 7月, 2007 1 次提交
  23. 06 7月, 2007 1 次提交
  25. 05 7月, 2007 1 次提交
  27. 29 6月, 2007 3 次提交
  29. 09 5月, 2007 1 次提交
  31. 20 4月, 2007 1 次提交
  33. 18 4月, 2007 1 次提交
    • S
      [MTD] Fix fwh_lock locking · e6be133b
      由 Shashi Rao 提交于 
      This is on a custom board with a mapping driver access to an ST
M50LPW080 chip. This chip is probed successfully with
do_map_probe("jedec_probe",...). If I use the mtdchar interface to
perform unlock->erase->program->lock on any of the 16 eraseblocks in the
chip, the chip is left in FL_STATUS mode while the data structures
believe that the chip is in FL_READY mode. Hence, any subsequent reads
to any flash byte results in 0x80 being read.
Signed-off-by: NShashi Rao <shashi@sun.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      e6be133b
  35. 03 4月, 2007 1 次提交
  37. 08 3月, 2007 1 次提交
  39. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      由 Tim Schmielau 提交于 
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there.  Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.

To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm.  I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  41. 09 2月, 2007 3 次提交
  43. 30 11月, 2006 1 次提交
  45. 29 11月, 2006 2 次提交
  47. 21 10月, 2006 3 次提交
  49. 04 10月, 2006 1 次提交
  51. 22 9月, 2006 1 次提交
  53. 16 9月, 2006 1 次提交
  55. 17 8月, 2006 2 次提交
  57. 15 8月, 2006 1 次提交
  59. 15 7月, 2006 1 次提交
    • A
      [MTD] Fixes of performance and stability issues in CFI driver. · 46a1652c
      由 Alexey Korolev 提交于 
      Fix of performance and stability issues on Intel NOR chips. It fixes:

1. Very low write performance on Sibley (perf tests demonstrated write
   performance less than 100Kb/sec when it should be over 400Kb/sec).

2. Low erase performance. (perf tests on Sibleuy demonstrated erase
   performance 246Kb/sec when it should be over 300Kb/sec).

3. Error on JFFS2 tests with CPU loading application when MTD returns
   "block erase error: (status timeout)" To fix the issue it does the
   following:
     1. Removes the timeout tuning from inval_cache_and_wait_for_operation.
     2. Waiting conditions in inval_cache_and_wait_for_operation now is
         based on timer resolution
        If timeout is lower than timer resolution then we do in cycle
	  "Checking the status"
	  udelay(1);
	  cond_resched();
        If timeout is greater than timer resolution (probably erase
        operation) We do the following
	  sleep for half of operation timeout and do in cycle the following
	    "Checking the status"
	    sleep for timer resolution
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NAlexey Korolev <akorolev@infradead.org>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      46a1652c