1. 05 4月, 2013 2 次提交
  2. 14 3月, 2013 1 次提交
  3. 07 7月, 2012 3 次提交
  4. 14 5月, 2012 1 次提交
  5. 10 1月, 2012 2 次提交
  6. 25 10月, 2010 1 次提交
    • B
      mtd: nand: support new Toshiba SLC · 13ed7aed
      Brian Norris 提交于
      Toshiba does not use ONFI for their NAND flash. So we have to continue
      to add new IDs used by Toshiba devices as well as heuristic detection
      for scanning the 2nd page for a BBM. This is a relatively harmless
      start at supporting many of them.
      
      These chips mostly follow the same ID fields of previous generations,
      but there is a need for a tweak.
      
      These chips introduce a strange 576 byte OOB (that's 36 bytes per
      512 bytes of page). In the preliminary data, Toshiba has not
      defined exactly how their ID strings should decode. In the future,
      a new tweak must be added.
      
      Data is taken from, among others, Toshiba TC58TxG4S2FBAxx
      Signed-off-by: NBrian Norris <norris@broadcom.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      13ed7aed
  7. 14 8月, 2010 1 次提交
  8. 02 8月, 2010 1 次提交
  9. 14 5月, 2010 1 次提交
  10. 05 6月, 2008 1 次提交
  11. 23 7月, 2007 1 次提交
  12. 18 4月, 2007 2 次提交
  13. 25 5月, 2006 1 次提交
    • T
      [MTD] NAND Introduce NAND_NO_READRDY option · 7a30601b
      Thomas Gleixner 提交于
      The nand driver has a superflous read ready / command
      delay in the read functions. This was added to handle
      chips which have an automatic read forward. Newer
      chips do not have this functionality anymore. Add this
      option to avoid the delay / I/O operation. Mark all
      large page chips with the new option flag.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      7a30601b
  14. 14 5月, 2006 1 次提交
  15. 07 11月, 2005 1 次提交
  16. 29 6月, 2005 1 次提交
  17. 27 5月, 2005 1 次提交
  18. 23 5月, 2005 2 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4