1. 13 11月, 2019 3 次提交
    • L
      mmc: mmci: sdmmc: add busy_complete callback · 0e68de6a
      Ludovic Barre 提交于
      This patch adds a specific busy_complete callback for sdmmc variant.
      
      sdmmc has 2 status flags:
      -busyd0: This is a hardware status flag (inverted value of d0 line).
      it does not generate an interrupt.
      -busyd0end: This indicates only end of busy following a CMD response.
      On busy to Not busy changes, an interrupt is generated (if unmask)
      and BUSYD0END status flag is set. Status flag is cleared by writing
      corresponding interrupt clear bit in MMCICLEAR.
      
      The legacy busy completion has no dedicated interrupt for the end
      of busy, so it's must monitor step by step the busy progression.
      On sdmmc variant, this procedure is not needed, it's just need
      to wait the busyd0end interrupt.
      Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      0e68de6a
    • L
      mmc: mmci: add busy_complete callback · cb0335b7
      Ludovic Barre 提交于
      This patch adds busy_completion callback at mmci_host_ops
      to allow to define a specific busy completion by variant.
      
      The legacy code corresponding to busy completion used
      by ux500 variants is moved to ux500_busy_complete function.
      Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cb0335b7
    • L
      mmc: mmci: add hardware busy timeout feature · 8266c585
      Ludovic Barre 提交于
      In the stm32_sdmmc variant, the datatimer is active not only during
      data transfers with the DPSM, but also while waiting for the busyend
      IRQs from commands having the MMC_RSP_BUSY flag set. This leads to an
      incorrect IRQ being raised to signal MCI_DATATIMEOUT error, which
      simply breaks the behaviour.
      
      Address this by updating the datatimer value before sending a command
      having the MMC_RSP_BUSY flag set. To inform the mmc core about the
      maximum supported busy timeout, which also depends on the current
      clock rate, set ->max_busy_timeout (in ms).
      Signed-off-by: NLudovic Barre <ludovic.barre@st.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      8266c585
  2. 19 6月, 2019 1 次提交
  3. 15 4月, 2019 6 次提交
  4. 25 2月, 2019 1 次提交
    • U
      mmc: mmci: Send a CMD12 to clear the DPSM at errors · e9968c6f
      Ulf Hansson 提交于
      The current approach with sending a CMD12 (STOP_TRANSMISSION) to complete a
      data transfer request, either because of using the open-ended transmission
      type or because of receiving an error during a pre-defined data transfer,
      isn't sufficient for the STM32 sdmmc variant. More precisely, this variant
      needs to clear the DPSM ("Data Path State Machine") by sending a CMD12, for
      all failing ADTC commands.
      
      Support this, by adding a struct mmc_command inside the struct mmci_host
      and initialize it to a CMD12 during ->probe(). Let's also add checks for
      the new conditions, to enable mmci_data_irq() and mmci_cmd_irq() to
      postpone the calls to mmci_request_end(), but instead send the CMD12.
      
      Cc: Ludovic Barre <ludovic.barre@st.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: NLudovic Barre <ludovic.barre@st.com>
      e9968c6f
  5. 17 12月, 2018 1 次提交
  6. 09 10月, 2018 20 次提交
  7. 08 10月, 2018 2 次提交
  8. 01 8月, 2018 1 次提交
  9. 30 7月, 2018 1 次提交
  10. 19 1月, 2018 2 次提交
  11. 13 2月, 2017 1 次提交
    • L
      mmc: core/mmci: restore pre/post_req behaviour · e13934bd
      Linus Walleij 提交于
      commit 64b12a68
      "mmc: core: fix prepared requests while doing bkops"
      is fixing a bug in the wrong way. A bug in the MMCI
      device driver is fixed by amending the MMC core.
      
      Thinking about it: what the pre- and post-callbacks
      are doing is to essentially map and unmap SG lists
      for DMA transfers. Why would we not be able to do that
      just because a BKOPS command is sent inbetween?
      Having to unprepare/prepare the next asynchronous
      request for DMA seems wrong.
      
      Looking the backtrace in that commit we can see what
      the real problem actually is:
      
      mmci_data_irq() is calling mmci_dma_unmap() twice
      which is goung to call arm_dma_unmap_sg() twice
      and v7_dma_inv_range() twice for the same sglist
      and that will crash.
      
      This happens because a request is prepared, then
      a BKOPS is sent. The IRQ completing the BKOPS command
      goes through mmci_data_irq() and thinks that a DMA
      operation has just been completed because
      dma_inprogress() reports true. It then proceeds to
      unmap the sglist.
      
      But that was wrong! dma_inprogress() should NOT be
      true because no DMA was actually in progress! We had
      just prepared the sglist, and the DMA channel
      dma_current has been configured, but NOT started!
      
      Because of this, the sglist is already unmapped when
      we get our actual data completion IRQ, and we are
      unmapping the sglist once more, and we get this crash.
      
      Therefore, we need to revert this solution pushing
      the problem to the core and causing problems, and
      instead augment the implementation such that
      dma_inprogress() only reports true if some DMA has
      actually been started.
      
      After this we can keep the request prepared during the
      BKOPS and we need not unprepare/reprepare it.
      
      Fixes: 64b12a68 ("mmc: core: fix prepared requests while doing bkops")
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Tested-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      e13934bd
  12. 29 11月, 2016 1 次提交
    • L
      mmc: mmci: refactor ST Micro busy detection · 49adc0ca
      Linus Walleij 提交于
      The ST Micro-specific busy detection was made after the assumption
      that only this variant supports busy detection. So when doing busy
      detection, the host immediately tries to use some ST-specific
      register bits.
      
      Since the qualcomm variant also supports some busy detection
      schemes, encapsulate the variant flags better in the variant struct
      and prepare to add more variants by just providing some bitmasks
      to the logic.
      
      Put the entire busy detection logic within an if()-clause in the
      mmci_cmd_irq() function so the code is only executed when busy
      detection is enabled, and so that it is kept in (almost) one
      place, and add comments describing what is going on so the
      code can be understood.
      
      Tested on the Ux500 by introducing some prints in the busy
      detection path and noticing how the IRQ is enabled, used and
      disabled successfully.
      
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      49adc0ca