1. 04 Mar, 2014 10 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 9 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
    • Ulf Hansson's avatar
      mmc: block: Use R1 responses for stop cmds for read requests · bcc3e172
      Ulf Hansson authored
      While using open ended transmission and thus ending the transfer by
      sending a stop command, we shall use R1B only for writes and R1 shall
      be used for reads. Previously R1B were used in both cases.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      bcc3e172
    • Ulf Hansson's avatar
      mmc: core: Respect host's max_busy_timeout when sending sleep cmd · cb962e04
      Ulf Hansson authored
      When sending the sleep command for host drivers supporting
      MMC_CAP_WAIT_WHILE_BUSY, we need to confirm that max_busy_timeout is
      big enough comparing to the sleep timeout specified from card's
      EXT_CSD. If this isn't case, we use a R1 response instead of R1B and
      fallback to use a delay instead.
      
      Do note that a max_busy_timeout set to zero by the host, is interpreted
      as it can cope with whatever timeout the mmc core provides it with.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      cb962e04
    • Ulf Hansson's avatar
      mmc: core: Use generic CMD6 time while switching to eMMC HS200 mode · 57de31f6
      Ulf Hansson authored
      Conform to the eMMC spec and use the CMD6 generic timeout from the
      EXT_CSD register, when switching to HS200 mode.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      57de31f6
    • Ulf Hansson's avatar
      mmc: core: Fixup busy detection for mmc switch operations · b9ec2616
      Ulf Hansson authored
      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: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarChris Ball <chris@printf.net>
      b9ec2616