1. 27 9月, 2016 12 次提交
  2. 22 9月, 2016 1 次提交
  3. 14 9月, 2016 2 次提交
  4. 12 9月, 2016 1 次提交
    • L
      mmc: sdhci-st: Handle interconnect clock · 3ae50f45
      Lee Jones 提交于
      Some ST platforms contain interconnect (ICN) clocks which must be handed
      correctly in order to obtain full functionality of a given IP.  In this
      case, if the ICN clocks are not handled properly by the ST SDHCI driver
      MMC will break and the following output can be observed:
      
          [   13.916949] mmc0: Timeout waiting for hardware interrupt.
          [   13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
          [   13.928175] sdhci: Sys addr: 0x00000000 | Version:  0x00001002
          [   13.933999] sdhci: Blk size: 0x00007040 | Blk cnt:  0x00000001
          [   13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
          [   13.945650] sdhci: Present:  0x1fff0206 | Host ctl: 0x00000011
          [   13.951475] sdhci: Power:    0x0000000f | Blk gap:  0x00000080
          [   13.957300] sdhci: Wake-up:  0x00000000 | Clock:    0x00003f07
          [   13.963126] sdhci: Timeout:  0x00000004 | Int stat: 0x00000000
          [   13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
          [   13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
          [   13.980602] sdhci: Caps:     0x21ed3281 | Caps_1:   0x00000000
          [   13.986428] sdhci: Cmd:      0x0000063a | Max curr: 0x00000000
          [   13.992252] sdhci: Host ctl2: 0x00000000
          [   13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
          [   14.001990] sdhci: ===========================================
          [   14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.
      
      A decent point was raised about minimising the use of a local variable that
      we 'could' do without.  I've chosen consistency over the possibility of
      reducing the local variable count by 1.  Thinking that it's more important
      for the code to be grouped and authoured in a similar manner/style for
      greater maintainability/readability.
      
      Cc: stable@vger.kernel.org
      Tested-by: NPeter Griffin <peter.griffin@linaro.org>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      3ae50f45
  5. 29 7月, 2016 8 次提交
  6. 27 7月, 2016 6 次提交
  7. 25 7月, 2016 10 次提交
    • D
      mmc: sdhci-of-arasan: Revert: Always power the PHY off/on when clock changes · 6fc09244
      Douglas Anderson 提交于
      This reverts commit 4ac0d5f245e1 ("mmc: sdhci-of-arasan: Always power
      the PHY off/on when clock changes"), resolving conflicts with other
      patches that have come after.  It appears that on some boards / with
      some eMMC devices that the patch is causing problems.
      
      Presumably turning the phy off and on again at the wrong time while
      initially setting up the card is confusing the card, the host, or the
      PHY.  We have lots of power cycles while initially setting up the card
      because the main sdhci driver often turns off the clock by clearing
      SDHCI_CLOCK_CARD_EN and then calls host->ops->set_clock() to set the
      clock again.  With all of those, we ended up with lots of power cycles.
      
      Presumably the arguments made in the original patch still hold.  That
      is, whenever the card clock is turned off and on again (or changed) we
      really should wait for the DLL to lock again.  However, perhaps it's
      really not that critical for the lower speeds.
      
      It's possible that the right answer here is:
      * Whenever set_clock() is called we should double-check that the DLL is
        locked.
      * Whenever set_clock() is called and we're actually changing clocks we
        should do a power cycle around that.
      * When we're doing a power cycle just because the clock changed, we
        probably shouldn't do quite as many things (maybe don't need to
        recalibarate, etc).
      
      Unfortunately the interaction between SDHCI and the PHY is extremely
      limited because of the limited PHY API.  The PHY does have a reference
      to the card clock and could theoretically register for notifications,
      except that our clock is query only (it uses CLK_GET_RATE_NOCACHE) and
      so can't really be notified about updates.  I believe we would need a
      major redesign of clock handling in SDHCI core to do better than that,
      or we would need to make our one fake notifications.  :(
      
      Let's hope that we can eventually get more information from Arasan on
      how all this should be handled before doing tons more work.  Until then,
      let's get back to a known working state.  Note that the rest of the
      patches in the 150 MHz series should still work fine even without this
      one.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6fc09244
    • G
      mmc: sdhci-msm: Add support for UHS cards · ad81d387
      Georgi Djakov 提交于
      Enabling support for ultra high speed mode cards requires some
      voltage switching and interaction with the PMIC via a special
      power IRQ. Add support for this.
      Signed-off-by: NGeorgi Djakov <georgi.djakov@linaro.org>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ad81d387
    • R
      mmc: sdhci-msm: Add set_uhs_signaling() implementation · ee320674
      Ritesh Harjani 提交于
      To allow UHS mode to work properly, we need to implement a Qualcomm
      specific set_uhs_signaling() callback function. This function differs
      from the sdhci_set_uhs_signaling() in that we need check the clock
      rate and enable UHS timing only if the frequency is above 100MHz.
      
      This patch resolves the mmc_select_hs200 timeouts noticed after merging
      commit a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after
      speed mode switch")
      
      mmc0: mmc_select_hs200 failed, error -110
      mmc0: error -110 whilst initialising MMC card
      mmc0: Reset 0x1 never completed.
      sdhci: =========== REGISTER DUMP (mmc0)===========
      sdhci: Sys addr: 0x00000000 | Version: 0x00002e02
      sdhci: Blk size: 0x00004000 | Blk cnt: 0x00000000
      sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
      sdhci: Present: 0x01f80000 | Host ctl: 0x00000000
      sdhci: Power: 0x00000000 | Blk gap: 0x00000000
      sdhci: Wake-up: 0x00000000 | Clock: 0x00000003
      sdhci: Timeout: 0x00000000 | Int stat: 0x00000000
      sdhci: Int enab: 0x00000000 | Sig enab: 0x00000000
      sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
      sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007
      sdhci: Cmd: 0x00000000 | Max curr: 0x00000000
      sdhci: Host ctl2: 0x00000000
      sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000000000000
      sdhci: ===========================================
      
      Fixes: a5c1f3e55c99 ("mmc: mmc: do not use CMD13 to get status after...")
      Signed-off-by: NRitesh Harjani <riteshh@codeaurora.org>
      Signed-off-by: NGeorgi Djakov <georgi.djakov@linaro.org>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ee320674
    • G
      mmc: sdhci-msm: Do not reset the controller if no card in the slot · 9718f84b
      Georgi Djakov 提交于
      The controller does not clear the "reset bit" when it is reset without
      a card in the slot. Because of this, the following error message is seen
      while booting with no plugged SD card.
      
      mmc1: Reset 0x1 never completed.
      
      Add the SDHCI_QUIRK_NO_CARD_NO_RESET quirk to avoid this.
      Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org>
      Signed-off-by: NGeorgi Djakov <georgi.djakov@linaro.org>
      Tested-by: NBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9718f84b
    • J
      mmc: tegra: Only advertise UHS modes if IO regulator is present · 4f6aa326
      Jon Hunter 提交于
      To support UHS modes for Tegra an external regulator must be present
      to adjust the IO voltage accordingly. Even if the regulator is not
      present but the host supports the UHS modes and the device supports the
      UHS modes, then we will attempt to switch to a high-speed mode. Without
      an external regulator, Tegra will fail to switch to the high-speed
      mode.
      
      It has been found that with some SD cards, that once it has been switch
      to operate at a high-speed mode, all subsequent commands issues to the
      card will fail and so it will not be possible to switch back to a non
      high-speed mode and so the SD card initialisation will fail.
      
      The SDHCI core does not require that the host have an external regulator
      when switching to UHS modes and therefore, the Tegra SDHCI host
      controller should only advertise the UHS modes as being supported if the
      regulator for the IO voltage is present. Fortunately, Tegra has a vendor
      specific register which can be used to control which modes are
      advertised via the SDHCI_CAPABILITIES register. Hence, if there is no IO
      voltage regulator available for the Tegra SDHCI host, then don't
      advertise the UHS modes.
      
      Note that if the regulator is not available, we also don't advertise that
      the SDHCI is compatible with v3.0 of the SDHCI specification because
      this will read the SDHCI_CAPABILITIES_1 register which will enable other
      UHS modes.
      
      This fixes commit 7ad2ed1d ("mmc: tegra: enable UHS-I modes") which
      enables UHS mode without checking if the board can support them.
      
      Fixes: 7ad2ed1d ("mmc: tegra: enable UHS-I modes")
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      4f6aa326
    • J
      mmc: sdhci: Request regulators before reading capabilities · efba142b
      Jon Hunter 提交于
      The capabilities of the SDHCI host controller are read early during the
      SDHCI host initialisation in sdhci_setup_host() and before any
      regulators for the host have been requested. This means that if the host
      supports some high-speed modes (according to its capabilities register),
      but the board cannot because the appropriate voltage regulator is not
      available, then the host cannot easily override the capabilities that
      are supported.
      
      To allow a SDHCI host controller to determine if it can support UHS high
      speed modes via the presence of the MMC regulators, request the
      regulators before reading the capabilities of the host controller. This
      will allow the SDHCI host to use the 'reset' callback to take the
      appropriate action (set flags, configure registers, etc) before the
      capabilities register(s) are read.
      
      Please note that some SDHCI hosts, such as the Tegra SDHCI host, has
      the ability to mask bits in the capabilities register to prevent
      certain capabilities from being advertised.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      efba142b
    • A
      sdhci-pci: Use MRFLD as abbreviation of Merrifield · 1f64cec2
      Andy Shevchenko 提交于
      Everywhere else in the code MRFLD abbreviation is used for Intel Merrifield. Do
      the same for sdhci-pci.
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      1f64cec2
    • D
      mmc: sdhci-esdhc-imx: clear tuning bits during driver probe · a75dcbf4
      Dong Aisheng 提交于
      The tuning bits like FBCLK_SEL, SMP_CLK_SEL and DLY_CELL which affects
      timing may have already been set by ROM if booting from SD3.0 mode like
      SDR104. Let's clear it first during driver probe before doing the new
      card enumeration to avoid working on the wrong timing.
      
      Note that tuning bits are dynamical settings which may need to be kept
      during MMC_PM_KEEP_POWER suspend, so we did not put them into hwinit
      function.
      Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a75dcbf4
    • D
      mmc: sdhci-esdhci-imx: re-initialize hw state after resume · 19dbfdd3
      Dong Aisheng 提交于
      sdhci_esdhc_imx_hwinit() includes all basic hw intialization.
      Calling it after resume to re-initialize hw in case its state
      is already lost in low power mode.
      Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      19dbfdd3
    • D
      mmc: sdhci-esdhc-imx: move tuning static configuration into hwinit function · 2b16cf32
      Dong Aisheng 提交于
      Move tuning static configuration into basic hwinit function.
      Tuning configuration may also be lost in low power mode, so
      need restore in hwinit().
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NDong Aisheng <aisheng.dong@nxp.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2b16cf32