1. 29 2月, 2016 1 次提交
  2. 22 12月, 2015 1 次提交
  3. 27 10月, 2015 1 次提交
    • C
      mmc: mmc: extend the mmc_send_tuning() · 9979dbe5
      Chaotian Jing 提交于
      The mmc_execute_tuning() has already prepared the opcode,
      there is no need to prepare it again at mmc_send_tuning(),
      and, there is a BUG of mmc_send_tuning() to determine the opcode
      by bus width, assume eMMC was running at HS200, 4bit mode,
      then the mmc_send_tuning() will overwrite the opcode from CMD21
      to CMD19, then got error.
      
      in addition, extend an argument of "cmd_error" to allow getting
      if there was cmd error when tune response.
      Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
      [Ulf: Rebased patch]
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9979dbe5
  4. 26 10月, 2015 1 次提交
  5. 01 6月, 2015 2 次提交
  6. 19 1月, 2015 1 次提交
  7. 08 12月, 2014 1 次提交
  8. 26 11月, 2014 1 次提交
  9. 10 11月, 2014 5 次提交
  10. 24 9月, 2014 1 次提交
  11. 09 9月, 2014 1 次提交
  12. 23 2月, 2014 4 次提交
    • U
      mmc: core: Fixup busy detection for mmc switch operations · b9ec2616
      Ulf Hansson 提交于
      If the host controller supports busy detection in HW, we expect the
      MMC_CAP_WAIT_WHILE_BUSY to be set. Likewise the corresponding
      host->max_busy_timeout should reflect the maximum busy detection
      timeout supported by the host.
      
      Previously we expected a host that supported MMC_CAP_WAIT_WHILE_BUSY to
      cope with any timeout, which just isn't feasible due to HW limitations.
      
      For most switch operations, R1B responses are expected and thus we need
      to check for busy detection completion. To cope with cases where the
      requested busy detection timeout is greater than what the host are able
      to support, we fallback to use a R1 response instead. This will prevent
      the host from doing HW busy detection.
      
      In those cases, busy detection completion is handled by polling the for
      the card's status using CMD13. This is the same mechanism used when the
      host doesn't support MMC_CAP_WAIT_WHILE_BUSY.
      
      Do note, a host->max_busy_timeout set to zero, is interpreted by the
      mmc core as it don't know what the host supports. It will then provide
      the host with whatever timeout the mmc core finds suitable.
      
      For some cases the mmc core has unfurtunate no clue of what timeout to
      use. In these cases we provide the host with a timeout value of zero,
      which the host may interpret as use whatever timeout it finds suitable.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <chris@printf.net>
      b9ec2616
    • U
      mmc: core: Minor simplifications to __mmc_switch · 636bd13c
      Ulf Hansson 提交于
      Instead of using several references to card->host, let's use a local
      variable. That means we can remove the BUG_ON verifications for the
      same pointers.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <chris@printf.net>
      636bd13c
    • U
      mmc: core: Add ignore_crc flag to __mmc_switch · 4509f847
      Ulf Hansson 提交于
      Instead of handle specific adaptations, releated to certain switch
      operations, inside __mmc_switch, push this to be handled by the caller
      instead.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <chris@printf.net>
      4509f847
    • U
      mmc: core: Rename cmd_timeout_ms to busy_timeout · 1d4d7744
      Ulf Hansson 提交于
      To better reflect that the cmd_timeout_ms is directly related to the
      busy detection timeout, let's rename it.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <chris@printf.net>
      1d4d7744
  13. 09 11月, 2013 1 次提交
  14. 31 10月, 2013 1 次提交
  15. 26 9月, 2013 1 次提交
  16. 25 8月, 2013 1 次提交
  17. 27 5月, 2013 2 次提交
    • U
      mmc: core: Restructure and simplify code for mmc sleep|awake · 07a68216
      Ulf Hansson 提交于
      The mmc_card_sleep|awake APIs are not being used since the support is
      already properly encapsulated within the suspend sequence. Sleep|awake
      command is also specific for eMMC.
      
      We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and
      move the code into the mmc specific core instead. This also includes
      the mmc ops function, mmc_sleepawake. All releated functions have then
      become static and we have got far less code to maintain.
      
      Additionally this patch also simplifies the code from mmc_sleepawake,
      since it is only used to put the card to sleep and not awake.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      07a68216
    • M
      mmc: card: Adding support for sanitize in eMMC 4.5 · 775a9362
      Maya Erez 提交于
      The sanitize support is added as a user-app ioctl call, and
      was removed from the block-device request, since its purpose is
      to be invoked not via File-System but by a user.
      
      This feature deletes the unmap memory region of the eMMC card,
      by writing to a specific register in the EXT_CSD.
      
      unmap region is the memory region that was previously deleted
      (by erase, trim or discard operation).
      
      In order to avoid timeout when sanitizing large-scale cards,
      the timeout for sanitize operation is 240 seconds.
      Signed-off-by: NYaniv Gardi <ygardi@codeaurora.org>
      Signed-off-by: NMaya Erez <merez@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      775a9362
  18. 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
  19. 07 12月, 2012 1 次提交
    • T
      mmc: core: Fix some driver hangs when dealing with broken devices · 8fee476b
      Trey Ramsay 提交于
      There are infinite loops in the mmc code that can be caused by bad
      hardware.  The code will loop forever if the device never comes back
      from program mode, R1_STATE_PRG, and it is not ready for data,
      R1_READY_FOR_DATA.
      
      A long timeout is added to prevent the code from looping forever.
      The timeout will occur if the device never comes back from program
      state or the device never becomes ready for data.
      
      It's not clear whether the timeout will do more than log a pr_err()
      and then start a fresh hang all over again.  We may need to extend
      this patch later to perform some kind of reset of the device (is
      that possible?) or rejection of new I/O to the device.
      Signed-off-by: NTrey Ramsay <tramsay@linux.vnet.ibm.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      8fee476b
  20. 03 10月, 2012 1 次提交
    • J
      mmc: support BKOPS feature for eMMC · 950d56ac
      Jaehoon Chung 提交于
      Enable eMMC background operations (BKOPS) feature.
      
      If URGENT_BKOPS is set after a response, note that BKOPS are required.
      Immediately run BKOPS if required.  Read/write operations should be
      requested during BKOPS(LEVEL-1), then issue HPI to interrupt the
      ongoing BKOPS and service the foreground operation.
      (This patch only controls the LEVEL2/3.)
      
      When repeating the writing 1GB data, at a certain time, performance is
      decreased.  At that time, card triggers the Level-3 or Level-2.  After
      running bkops, performance is recovered.
      
      Future considerations:
       * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
       * Interrupt ongoing BKOPS before powering off the card.
       * How do we get BKOPS_STATUS value (periodically send ext_csd command)?
       * If using periodic bkops, also consider runtime_pm control.
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NKonstantin Dorfman <kdorfman@codeaurora.org>
      Reviewed-by: NMaya Erez <merez@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      950d56ac
  21. 19 9月, 2012 1 次提交
    • K
      mmc: core: Remove bounce buffer in mmc_send_cxd_data() · 1a41313e
      Kyungsik Lee 提交于
      It is expected that Extended CSD register (the size of this register
      is larger than CID/CSD) will be referenced more frequently as more
      fields have been added to Extended CSD and it seems that it is not
      a good option to double the memory used.
      
      This patch is intended to avoid the use of bounce buffer for reading
      Extended CSD register in mmc_send_cxd_data(). It will provide a better
      performance gain by removing memcpy() overhead for a half KiB and
      a redundant bounce buffer allocated repeatedly at the cost of providing
      DMA-capable buffer from upper caller (but on-stack buffer is allowed
      with no performance gain).
      Signed-off-by: NKyungsik Lee <kyungsik.lee@lge.com>
      Reviewed-by: NVenkatraman S <svenkatr@ti.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      1a41313e
  22. 11 7月, 2012 1 次提交
  23. 28 3月, 2012 1 次提交
  24. 01 11月, 2011 1 次提交
  25. 27 10月, 2011 3 次提交
  26. 14 8月, 2011 1 次提交
  27. 25 5月, 2011 3 次提交