1. 08 6月, 2016 2 次提交
  2. 01 6月, 2015 1 次提交
  3. 06 5月, 2015 1 次提交
    • C
      mmc: card: Don't access RPMB partitions for normal read/write · 4e93b9a6
      Chuanxiao Dong 提交于
      During kernel boot, it will try to read some logical sectors
      of each block device node for the possible partition table.
      
      But since RPMB partition is special and can not be accessed
      by normal eMMC read / write CMDs, it will cause below error
      messages during kernel boot:
      ...
       mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
       mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
       mmcblk0rpmb: retrying using single block read
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
       end_request: I/O error, dev mmcblk0rpmb, sector 0
       Buffer I/O error on device mmcblk0rpmb, logical block 0
       end_request: I/O error, dev mmcblk0rpmb, sector 8
       Buffer I/O error on device mmcblk0rpmb, logical block 1
       end_request: I/O error, dev mmcblk0rpmb, sector 16
       Buffer I/O error on device mmcblk0rpmb, logical block 2
       end_request: I/O error, dev mmcblk0rpmb, sector 24
       Buffer I/O error on device mmcblk0rpmb, logical block 3
      ...
      
      This patch will discard the access request in eMMC queue if
      it is RPMB partition access request. By this way, it avoids
      trigger above error messages.
      
      Fixes: 090d25fe ("mmc: core: Expose access to RPMB partition")
      Signed-off-by: NYunpeng Gao <yunpeng.gao@intel.com>
      Signed-off-by: NChuanxiao Dong <chuanxiao.dong@intel.com>
      Tested-by: NMichael Shigorin <mike@altlinux.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      4e93b9a6
  4. 23 3月, 2013 1 次提交
    • S
      mmc: block: fix the host's claim-release in special request · ef3a69c7
      Seungwon Jeon 提交于
      For normal request mmc_blk_issue_rq is called twice with asynchronous
      transfer(cur and prev). Host's claim and release can be done in each
      mmc_blk_issue_rq. However, Special request is currently excluded in
      asynchronous transfer. After special request is finished, if there is
      no new request, mmc_release_host won't be called in mmc_blk_issue_rq.
      The problem is founded during mmc_suspend.
      
      [<c0541124>] (__schedule+0x0/0x78c) from [<c05419e8>] (schedule+0x38/0x78)
      [<c05419b0>] (schedule+0x0/0x78) from [<c03a843c>] (__mmc_claim_host+0xac/0x1b4)
      [<c03a8390>] (__mmc_claim_host+0x0/0x1b4) from [<c03ac98c>] (mmc_suspend+0x28/0x9c)
      [<c03ac964>] (mmc_suspend+0x0/0x9c) from [<c03aad24>] (mmc_suspend_host+0xb4/0x194)
      ...
      Reported-by: NJohan Rudholm <jrudholm@gmail.com>
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Tested-by: NJohan Rudholm <johan.rudholm@stericsson.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      ef3a69c7
  5. 25 2月, 2013 1 次提交
    • S
      mmc: support packed write command for eMMC4.5 devices · ce39f9d1
      Seungwon Jeon 提交于
      This patch supports packed write command of eMMC4.5 devices.  Several
      writes can be grouped in packed command and all data of the individual
      commands can be sent in a single transfer on the bus. Large amounts of
      data in one transfer rather than several data of small size are
      effective for eMMC write internally.  As a result, packed command help
      write throughput be improved.  The following tables show the results
      of packed write.
      
      Type A:
      test     none |  packed
      iozone   25.8 |  31
      tiotest  27.6 |  31.2
      lmdd     31.2 |  35.4
      
      Type B:
      test     none |  packed
      iozone   44.1 |  51.1
      tiotest  47.9 |  52.5
      lmdd     51.6 |  59.2
      
      Type C:
      test     none |  packed
      iozone   19.5 |  32
      tiotest  19.9 |  34.5
      lmdd     22.8 |  40.7
      Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Reviewed-by: NMaya Erez <merez@codeaurora.org>
      Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      ce39f9d1
  6. 12 2月, 2013 1 次提交
    • K
      mmc: fix async request mechanism for sequential read scenarios · 2220eedf
      Konstantin Dorfman 提交于
      When current request is running on the bus and if next request fetched
      by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
      current request completes. This means that if new request comes in while
      the mmcqd thread is blocked, this new request can not be prepared in
      parallel to current ongoing request. This may result in delaying the new
      request execution and increase it's latency.
      
      This change allows to wake up the MMC thread on new request arrival.
      Now once the MMC thread is woken up, a new request can be fetched and
      prepared in parallel to the current running request which means this new
      request can be started immediately after the current running request
      completes.
      
      With this change read throughput is improved by 16%.
      Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      2220eedf
  7. 28 1月, 2013 1 次提交
    • K
      mmc: fix async request mechanism for sequential read scenarios · 6035d973
      Konstantin Dorfman 提交于
      When current request is running on the bus and if next request fetched
      by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the
      current request completes. This means that if new request comes in while
      the mmcqd thread is blocked, this new request can not be prepared in
      parallel to current ongoing request. This may result in delaying the new
      request execution and increase it's latency.
      
      This change allows to wake up the MMC thread on new request arrival.
      Now once the MMC thread is woken up, a new request can be fetched and
      prepared in parallel to the current running request which means this new
      request can be started immediately after the current running request
      completes.
      
      With this change read throughput is improved by 16%.
      Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: NSeungwon Jeon <tgih.jun@samsung.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      6035d973
  8. 21 7月, 2011 3 次提交
  9. 26 6月, 2011 1 次提交
  10. 10 7月, 2007 1 次提交
  11. 24 5月, 2007 1 次提交
  12. 01 5月, 2007 2 次提交
  13. 02 12月, 2006 1 次提交
  14. 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