1. 04 Mar, 2014 14 commits
  2. 03 Mar, 2014 7 commits
  3. 27 Feb, 2014 3 commits
  4. 25 Feb, 2014 10 commits
  5. 24 Feb, 2014 1 commit
  6. 23 Feb, 2014 5 commits
    • Ulf Hansson's avatar
      mmc: mmci: Enable support for busy detection for ux500 variant · 8d94b54d
      Ulf Hansson authored
      The ux500 variants have HW busy detection support, which is indicated
      by the busy_detect flag. For these variants let's enable the
      MMC_CAP_WAIT_WHILE_BUSY flag and add the support for it.
      
      The mmc core will provide the RSP_BUSY command flag for those requests
      we should care about busy detection. Regarding the max_busy_timeout,
      the HW don't support busy detection timeouts so at this initial step
      let's make it simple and set it to zero to indicate we are able to
      support any timeout.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Johan Rudholm <jrudholm@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      8d94b54d
    • Ulf Hansson's avatar
      mmc: mmci: Handle CMD irq before DATA irq · e7f3d222
      Ulf Hansson authored
      In case of a read operation both MCI_CMDRESPEND and MCI_DATAEND can be
      set in the status register when entering the interrupt handler. This is
      due to that the card start sending data before the host has
      acknowledged the command response.
      
      To resolve the issue for this scenario, we must start by handling the
      CMD irq instead of the DATA irq. The reason is beacuse the completion
      of the DATA irq will not respect the current command and then causing
      it to be garbled.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Johan Rudholm <jrudholm@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      e7f3d222
    • Ulf Hansson's avatar
      mmc: block: Fixup busy detection while invoking stop cmd at recovery · bb5cba40
      Ulf Hansson authored
      When sending a stop command at the recovery path, use a R1B response
      when the failing data request are a WRITE. Thus we also care about the
      busy detection completion in this case.
      
      For a failing READ request, we use a R1 response for the stop command,
      since we don't need to care about busy detection in this case.
      
      To align behavior between hosts supporting MMC_CAP_WAIT_WHILE_BUSY and
      those who are not, we add a CMD13 polling method for the card's status.
      
      We also respect whether the host has specified the max_busy_timeout,
      which means we may fallback to CMD13 polling if the timeout is greater
      than what the host are able to support.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      bb5cba40
    • Ulf Hansson's avatar
      mmc: block: Respect hw busy detection in card_busy_detect() · 95a91298
      Ulf Hansson authored
      Currently for write request we don't trust the hw busy detection to be
      fully handled by host, thus we also poll the card's status until we see
      it's gets out of the busy state.
      
      Still there are scenarios where it will a benefit to trust the hw busy
      detection done by the host, since no additional polling is needed.
      Let's prepare card_busy_detect() to be able to handle this.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      95a91298
    • Ulf Hansson's avatar
      mmc: block: Implement card_busy_detect() for busy detection · c49433fb
      Ulf Hansson authored
      To complete a data write request we poll for the card's status register
      by sending CMD13. The are other scenarios when this polling method are
      needed, which is why we here moves this code to it's own function. No
      functional change.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      c49433fb