1. 25 10月, 2010 8 次提交
  2. 09 8月, 2010 1 次提交
  3. 02 8月, 2010 1 次提交
  4. 14 5月, 2010 2 次提交
    • K
      mtd: nand: support alternate BB marker locations on MLC · b60b08b0
      Kevin Cernekee 提交于
      This is a slightly modified version of a patch submitted last year by
      Reuben Dowle <reuben.dowle@navico.com>.  His original comments follow:
      
      This patch adds support for some MLC NAND flashes that place the BB
      marker in the LAST page of the bad block rather than the FIRST page used
      for SLC NAND and other types of MLC nand.
      
      Lifted from Samsung datasheet for K9LG8G08U0A (1Gbyte MLC NAND):
      "
      Identifying Initial Invalid Block(s)
      All device locations are erased(FFh) except locations where the initial
      invalid block(s) information is written prior to shipping. The initial
      invalid block(s) status is defined by the 1st byte in the spare area.
      Samsung makes sure that the last page of every initial invalid block has
      non-FFh data at the column address of 2,048.
      ...
      "
      
      As far as I can tell, this is the same for all Samsung MLC nand, and in
      fact the samsung bsp for the processor used in our project (s3c6410)
      actually contained a hack similar to this patch but less portable to
      enable use of their NAND parts. I discovered this problem when trying to
      use a Micron NAND which does not used this layout - I wish samsung would
      put their stuff in main-line to avoid this type of problem.
      
      Currently this patch causes all MLC nand with manufacturer codes from
      Samsung and ST(Numonyx) to use this alternative location, since these
      are the manufactures that I know of that use this layout.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      b60b08b0
    • K
      mtd: nand: extend NAND flash detection to new MLC chips · 426c457a
      Kevin Cernekee 提交于
      Some of the newer MLC devices have a 6-byte ID sequence in which
      several field definitions differ from older chips in a manner that is
      not backward compatible.  For instance:
      
      Samsung K9GAG08U0M (5-byte sequence): ec d5 14 b6 74
      4th byte, bits 1:0 encode the page size: 0=1KiB, 1=2KiB, 2=4KiB, 3=8KiB
      4th byte, bits 5:4 encode the block size: 0=64KiB, 1=128KiB, ...
      4th byte, bit 6 encodes the OOB size: 0=8B/512B, 1=16B/512B
      
      Samsung K9GAG08U0D (6-byte sequence): ec d5 94 29 34 41
      4th byte, bits 1:0 encode the page size: 0=2KiB, 1=4KiB, 3=8KiB, 4=rsvd
      4th byte, bits 7;5:4 encode the block size: 0=128KiB, 1=256KiB, ...
      4th byte, bits 6;3:2 encode the OOB size: 1=128B/page, 2=218B/page
      
      This patch uses the new 6-byte scheme if the following conditions are
      all true:
      
      1) The ID code wraps around after exactly 6 bytes
      
      2) Manufacturer is Samsung
      
      3) 6th byte is zero
      
      The patch also extends the maximum OOB size from 128B to 256B.
      Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      426c457a
  5. 27 2月, 2010 3 次提交
  6. 26 2月, 2010 1 次提交
  7. 30 11月, 2009 1 次提交
  8. 25 9月, 2009 2 次提交
  9. 20 9月, 2009 2 次提交
  10. 06 6月, 2009 3 次提交
  11. 06 4月, 2009 1 次提交
  12. 11 12月, 2008 1 次提交
    • R
      [MTD] [NAND] remove excess kernel-doc notation · d3af0f04
      Randy Dunlap 提交于
      Delete extra kernel-doc notation for struct fields and function
      parameters that don't exist:
      
      Warning(include/linux/mtd/nand.h:428): Excess struct/union/enum/typedef member 'wq' description in 'nand_chip'
      Warning(include/linux/mtd/nand.h:428): Excess struct/union/enum/typedef member 'datbuf' description in 'nand_chip'
      Warning(include/linux/mtd/nand.h:428): Excess struct/union/enum/typedef member 'oobbuf' description in 'nand_chip'
      Warning(include/linux/mtd/nand.h:428): Excess struct/union/enum/typedef member 'oobdirty' description in 'nand_chip'
      Warning(include/linux/mtd/nand.h:428): Excess struct/union/enum/typedef member 'data_poi' description in 'nand_chip'
      Warning(drivers/mtd/nand/nand_base.c:2527): Excess function parameter 'maxchips' description in 'nand_scan_tail'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      d3af0f04
  13. 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
  14. 21 8月, 2008 1 次提交
  15. 30 7月, 2008 1 次提交
  16. 25 7月, 2008 1 次提交
  17. 07 6月, 2008 1 次提交
  18. 05 6月, 2008 1 次提交
  19. 23 7月, 2007 1 次提交
  20. 08 5月, 2007 1 次提交
  21. 18 4月, 2007 1 次提交
  22. 09 2月, 2007 1 次提交
  23. 29 11月, 2006 1 次提交
  24. 31 10月, 2006 1 次提交
  25. 22 10月, 2006 1 次提交
  26. 26 9月, 2006 1 次提交