1. 04 Mar, 2014 16 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 3 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