1. 16 7月, 2018 1 次提交
    • S
      mmc: core: Adjust and reuse the macro of R1_STATUS(x) · a94a7483
      Shawn Lin 提交于
      R1_STATUS(x) now is only used by ioctl_rpmb_card_status_poll(),
      which checks all bits as possible. But according to the spec,
      bit 17 and bit 18 should be ignored, as well bit 14 which is
      reserved(must be set to 0) quoting from the spec and these rule
      apply to all places checking the device status. So change
      its checking from 0xFFFFE000 to 0xFFF9A000.
      
      As a bonus, we reuse it for mmc_do_erase() as well as
      mmc_switch_status_error().
      (1) Currently mmc_switch_status_error() doesn't check bit 25, but
      it means device is locked but not unlocked by CMD42 prior to any
      operations which need check busy, which is also not allowed.
      (2) mmc_do_erase() also forgot to to check bit 15, WP_ERASE_SKIP.
      The spec says "Only partial address space was erased due to existing
      write protected blocks.", which obviously means we should fail this I/O.
      Otherwise, the partial erased data stored in nonvalatile flash violates
      the data integrity from the view of I/O owner, which probably confuse
      it when further used.
      
      So reusing R1_STATUS for them not only improve the readability but also
      slove real problems.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a94a7483
  2. 14 2月, 2017 1 次提交
  3. 13 2月, 2017 4 次提交
  4. 05 12月, 2016 1 次提交
  5. 25 7月, 2016 1 次提交
  6. 01 6月, 2015 2 次提交
  7. 29 1月, 2015 1 次提交
  8. 19 1月, 2015 1 次提交
  9. 10 11月, 2014 1 次提交
  10. 23 9月, 2014 1 次提交
  11. 19 9月, 2014 1 次提交
  12. 13 5月, 2014 3 次提交
  13. 25 2月, 2013 1 次提交
  14. 07 12月, 2012 1 次提交
  15. 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
  16. 09 5月, 2012 1 次提交
  17. 26 3月, 2012 1 次提交
  18. 13 1月, 2012 1 次提交
  19. 12 1月, 2012 1 次提交
  20. 27 10月, 2011 8 次提交
  21. 21 7月, 2011 2 次提交
  22. 26 5月, 2011 1 次提交
  23. 25 5月, 2011 4 次提交