1. 23 12月, 2008 1 次提交
  2. 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
  3. 25 7月, 2008 1 次提交
    • A
      UBI: always start the background thread · d37e6bf6
      Artem Bityutskiy 提交于
      This fix only affects UBI debugging.
      
      If the the background thread is disabled for debugging purposes,
      start it anyway, because otherwise we see tonns of kernel debugging
      complaints like this:
      
      INFO: task ubi_bgt0d:26857 blocked for more than 120 seconds.
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      ubi_bgt0d     D dd37bf94     0 26857      2
             dd37bfcc 00000086 f8e17cea dd37bf94 00000046 00000000 00000000 f5c62430
             f5c62430 f5c62590 c2a09c80 f6cbd498 dd8e9cbc 00000296 dd37bfb0 00000296
             dd8e9cb8 dd8e9cbc dd37bfcc c0119774 00000000 00000000 c0132e89 f6961560
      Call Trace:
       [<f8e17cea>] ? ubi_thread+0x0/0x127 [ubi]
       [<c0119774>] ? complete+0x43/0x4b
       [<c0132e89>] ? kthread+0x0/0x5b
       [<f8e17cea>] ? ubi_thread+0x0/0x127 [ubi]
       [<c0132eae>] kthread+0x25/0x5b
       [<c0132e89>] ? kthread+0x0/0x5b
       [<c0104953>] kernel_thread_helper+0x7/0x14
       =======================
      
      So start it, and go sleep inside it, instead of creating it and never
      start.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      d37e6bf6
  4. 24 7月, 2008 9 次提交
  5. 23 4月, 2008 1 次提交
  6. 20 4月, 2008 1 次提交
  7. 17 4月, 2008 1 次提交
  8. 04 3月, 2008 1 次提交
  9. 25 1月, 2008 4 次提交
    • A
      UBI: bugfix: calculate data offset properly · d5360587
      Artem Bityutskiy 提交于
      Data offset is VID header offset + VID header size aligned to
      the min. I/O unit size up.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      d5360587
    • A
      UBI: amend array size · ddc49391
      Artem Bityutskiy 提交于
      Since the data offset parameter was removed, the size of
      the parameters array is now 2, not 3.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      ddc49391
    • A
      UBI: add auto-resize feature · 4ccf8cff
      Artem Bityutskiy 提交于
      The problem: NAND flashes have different amount of initial bad physical
      eraseblocks (marked as bad by the manufacturer). For example, for 256MiB
      Samsung OneNAND flash there might be from 0 to 40 bad initial eraseblocks,
      which is about 2%. When UBI is used as the base system, one needs to know
      the exact amount of good physical eraseblocks, because this number is
      needed to create the UBI image which is put to the devices during
      production. But this number is not know, which forces us to use the
      minimum number of good physical eraseblocks. And UBI additionally
      reserves some percentage of physical eraseblocks for bad block handling
      (default is 1%), so we have 1-3% of PEBs reserved at the end, depending
      on the amount of initial bad PEBs. But it is desired to always have
      1% (or more, depending on the configuration).
      
      Solution: this patch adds an "auto-resize" flag to the volume table.
      The volume which has the "auto-resize" flag will automatically be re-sized
      (enlarged) on the first UBI initialization. UBI clears the flag when
      the volume is re-sized. Only one volume may have the "auto-resize" flag.
      
      So, the production UBI image may have one volume with "auto-resize"
      flag set, and its size is automatically adjusted on the first boot
      of the device.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      4ccf8cff
    • A
      UBI: get rid of ubi_ltree_slab · b9a06623
      Artem Bityutskiy 提交于
      This slab cache is not really needed since the number of objects
      is low and the constructor does not make much sense because we
      allocate oblects when doint I/O, which is way slower then allocation.
      Suggested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      b9a06623
  10. 27 12月, 2007 20 次提交