1. 24 5月, 2016 6 次提交
  2. 05 4月, 2016 1 次提交
    • K
      mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros · 09cbfeaf
      Kirill A. Shutemov 提交于
      PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
      ago with promise that one day it will be possible to implement page
      cache with bigger chunks than PAGE_SIZE.
      
      This promise never materialized.  And unlikely will.
      
      We have many places where PAGE_CACHE_SIZE assumed to be equal to
      PAGE_SIZE.  And it's constant source of confusion on whether
      PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
      especially on the border between fs and mm.
      
      Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
      breakage to be doable.
      
      Let's stop pretending that pages in page cache are special.  They are
      not.
      
      The changes are pretty straight-forward:
      
       - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
      
       - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
      
       - page_cache_get() -> get_page();
      
       - page_cache_release() -> put_page();
      
      This patch contains automated changes generated with coccinelle using
      script below.  For some reason, coccinelle doesn't patch header files.
      I've called spatch for them manually.
      
      The only adjustment after coccinelle is revert of changes to
      PAGE_CAHCE_ALIGN definition: we are going to drop it later.
      
      There are few places in the code where coccinelle didn't reach.  I'll
      fix them manually in a separate patch.  Comments and documentation also
      will be addressed with the separate patch.
      
      virtual patch
      
      @@
      expression E;
      @@
      - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      expression E;
      @@
      - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
      + E
      
      @@
      @@
      - PAGE_CACHE_SHIFT
      + PAGE_SHIFT
      
      @@
      @@
      - PAGE_CACHE_SIZE
      + PAGE_SIZE
      
      @@
      @@
      - PAGE_CACHE_MASK
      + PAGE_MASK
      
      @@
      expression E;
      @@
      - PAGE_CACHE_ALIGN(E)
      + PAGE_ALIGN(E)
      
      @@
      expression E;
      @@
      - page_cache_get(E)
      + get_page(E)
      
      @@
      expression E;
      @@
      - page_cache_release(E)
      + put_page(E)
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      09cbfeaf
  3. 03 4月, 2016 1 次提交
  4. 21 3月, 2016 1 次提交
  5. 12 3月, 2016 1 次提交
  6. 11 3月, 2016 2 次提交
    • A
      mtd: nand: Qualcomm NAND controller driver · c76b78d8
      Archit Taneja 提交于
      The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx,
      MDM9x15 series.
      
      It exists as a sub block inside the IPs EBI2 (External Bus Interface 2)
      and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a
      broader interface for external slow peripheral devices such as LCD and
      NAND/NOR flash memory or SRAM like interfaces.
      
      We add support for the NAND controller found within EBI2. For the SoCs
      of our interest, we only use the NAND controller within EBI2. Therefore,
      it's safe for us to assume that the NAND controller is a standalone block
      within the SoC.
      
      The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND
      flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and
      16 bit correction/step) and RS ECC(4 bit correction/step) that covers main
      and spare data. The controller contains an internal 512 byte page buffer
      to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA
      for register read/write and data transfers. The controller performs page
      reads and writes at a codeword/step level of 512 bytes. It can support up
      to 2 external chips of different configurations.
      
      The driver prepares register read and write configuration descriptors for
      each codeword, followed by data descriptors to read or write data from the
      controller's internal buffer. It uses a single ADM DMA channel that we get
      via dmaengine API. The controller requires 2 ADM CRCIs for command and
      data flow control. These are passed via DT.
      
      The ecc layout used by the controller is syndrome like, but we can't use
      the standard syndrome ecc ops because of several reasons. First, the amount
      of data bytes covered by ecc isn't same in each step. Second, writing to
      free oob space requires us writing to the entire step in which the oob
      lies. This forces us to create our own ecc ops.
      
      One more difference is how the controller accesses the bad block marker.
      The controller ignores reading the marker when ECC is enabled. ECC needs
      to be explicity disabled to read or write to the bad block marker. The
      nand_bbt helpers library hence can't access BBMs for the controller.
      For now, we skip the creation of BBT and populate chip->block_bad and
      chip->block_markbad helpers instead.
      Reviewed-by: NAndy Gross <agross@codeaurora.org>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c76b78d8
    • A
      mtd: nand: don't select chip in nand_chip's block_bad op · 9f3e0429
      Archit Taneja 提交于
      One of the arguments passed to struct nand_chip's block_bad op is
      'getchip', which, if true, is supposed to get and select the nand device,
      and later unselect and release the device.
      
      This op is intended to be replaceable by drivers. The drivers shouldn't
      be responsible for selecting/unselecting chip. Like other ops, the chip
      should already be selected before the block_bad op is called.
      
      Remove the getchip argument from the block_bad op and
      nand_block_checkbad. Move the chip selection to nand_block_isbad, since it
      is the only caller to nand_block_checkbad which requires chip selection.
      
      Modify nand_block_bad (the default function for the op) such that it
      doesn't select the chip.
      
      Remove the getchip argument from the bad_block funcs in cafe_nand,
      diskonchip and docg4 drivers.
      Reviewed-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: NArchit Taneja <architt@codeaurora.org>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      9f3e0429
  7. 08 3月, 2016 19 次提交
  8. 06 3月, 2016 1 次提交
  9. 05 3月, 2016 4 次提交
  10. 01 3月, 2016 1 次提交
  11. 25 2月, 2016 1 次提交
  12. 16 2月, 2016 1 次提交
  13. 13 2月, 2016 1 次提交
    • C
      mtd: spi-nor: remove micron_quad_enable() · 3b5394a3
      Cyrille Pitchen 提交于
      This patch remove the micron_quad_enable() function which force the Quad
      SPI mode. However, once this mode is enabled, the Micron memory expect ALL
      commands to use the SPI 4-4-4 protocol. Hence a failure does occur when
      calling spi_nor_wait_till_ready() right after the update of the Enhanced
      Volatile Configuration Register (EVCR) in the micron_quad_enable() as
      the SPI controller driver is not aware about the protocol change.
      
      Since there is almost no performance increase using Fast Read 4-4-4
      commands instead of Fast Read 1-1-4 commands, we rather keep on using the
      Extended SPI mode than enabling the Quad SPI mode.
      
      Let's take the example of the pretty standard use of 8 dummy cycles during
      Fast Read operations on 64KB erase sectors:
      
      Fast Read 1-1-4 requires 8 cycles for the command, then 24 cycles for the
      3byte address followed by 8 dummy clock cycles and finally 65536*2 cycles
      for the read data; so 131112 clock cycles.
      
      On the other hand the Fast Read 4-4-4 would require 2 cycles for the
      command, then 6 cycles for the 3byte address followed by 8 dummy clock
      cycles and finally 65536*2 cycles for the read data. So 131088 clock
      cycles. The theorical bandwidth increase is 0.0%.
      
      Now using Fast Read operations on 512byte pages:
      Fast Read 1-1-4 needs 8+24+8+(512*2) = 1064 clock cycles whereas Fast
      Read 4-4-4 would requires 2+6+8+(512*2) = 1040 clock cycles. Hence the
      theorical bandwidth increase is 2.3%.
      Consecutive reads for non sequential pages is not a relevant use case so
      The Quad SPI mode is not worth it.
      
      mtd_speedtest seems to confirm these figures.
      Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
      Fixes: 548cd3ab ("mtd: spi-nor: Add quad I/O support for Micron SPI NOR")
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      3b5394a3
新手
引导
客服 返回
顶部