1. 16 7月, 2018 2 次提交
    • S
      mmc: tegra: prevent HS200 on Tegra 3 · 127407e3
      Stefan Agner 提交于
      The stack assumes that SDHC controller which support SD3.0 (SDR104) do
      support HS200. This is not the case for Tegra 3, which does support SD
      3.0
      but only supports eMMC spec 4.41.
      
      Use SDHCI_QUIRK2_BROKEN_HS200 to indicate that the controller does not
      support HS200.
      
      Note that commit 156e14b1 ("mmc: sdhci: fix caps2 for HS200") added
      the tie between SD3.0 (SDR104) and HS200. I don't think that this is
      necessarly true. It is fully legitimate to support SD3.0 and not support
      HS200. The quirk naming suggests something is broken in the controller,
      but this is not the case: The controller simply does not support HS200.
      
      Fixes: 7ad2ed1d ("mmc: tegra: enable UHS-I modes")
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Tested-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      127407e3
    • A
      mmc: tegra: Use sdhci_pltfm_clk_get_max_clock · 75067aba
      Aapo Vienamo 提交于
      The sdhci get_max_clock callback is set to sdhci_pltfm_clk_get_max_clock
      and tegra_sdhci_get_max_clock is removed. It appears that the
      shdci-tegra specific callback was originally introduced due to the
      requirement that the host clock has to be twice the bus clock on DDR50
      mode. As far as I can tell the only effect the removal has on DDR50 mode
      is in cases where the parent clock is unable to supply the requested
      clock rate, causing the DDR50 mode to run at a lower frequency.
      Currently the DDR50 mode isn't enabled on any of the SoCs and would also
      require configuring the SDHCI clock divider register to function
      properly.
      
      The problem with tegra_sdhci_get_max_clock is that it divides the clock
      rate by two and thus artificially limits the maximum frequency of faster
      signaling modes which don't have the host-bus frequency ratio requirement
      of DDR50 such as SDR104 and HS200. Furthermore, the call to
      clk_round_rate() may return an error which isn't handled by
      tegra_sdhci_get_max_clock.
      Signed-off-by: NAapo Vienamo <avienamo@nvidia.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Tested-by: NThierry Reding <treding@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      75067aba
  2. 08 5月, 2018 1 次提交
  3. 30 10月, 2017 1 次提交
  4. 30 8月, 2017 2 次提交
  5. 25 4月, 2017 2 次提交
  6. 27 9月, 2016 1 次提交
  7. 29 7月, 2016 1 次提交
  8. 25 7月, 2016 1 次提交
    • 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
  9. 14 4月, 2016 1 次提交
    • J
      mmc: tegra: Disable UHS-I modes for Tegra124 · 70ad7f7e
      Jon Hunter 提交于
      Tegra124 has been randomly hanging during system suspend when entering
      the Tegra LP1 low power state. The hang is caused by the Tegra SDHCI
      driver and linked to the UHS-I tuning sequence. Disabling the UHS-I
      modes for Tegra124 prevents any hangs from occurring when entering
      system suspend.
      
      Unfortunately, the tuning sequence described in the public Tegra
      documentation is incomplete and on inspection of the current tuning
      sequence that has been implemented is also incomplete and may cause
      problems. In the short-term it is safer to disable UHS-I modes for now
      and fix later because it would be too large of a change to simply patch
      now. Therefore, disable UHS-I modes for Tegra124.
      Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      70ad7f7e
  10. 17 3月, 2016 2 次提交
  11. 16 3月, 2016 1 次提交
  12. 29 2月, 2016 1 次提交
  13. 06 1月, 2016 2 次提交
  14. 28 12月, 2015 3 次提交
    • L
      mmc: tegra: implement UHS tuning · c3c2384c
      Lucas Stach 提交于
      This implements the UHS tuning sequence in a similar way to the one
      contained in the TRM. It deviates in the way how to check if the tap
      value is passing, by using the common Linux MMC function, which does
      not only check for data CRC errors, but also if the received block
      pattern is correct.
      Signed-off-by: NLucas Stach <dev@lynxeye.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c3c2384c
    • L
      mmc: tegra: disable SPI_MODE_CLKEN · 74cd42bc
      Lucas Stach 提交于
      The Tegra30 and up TRM states that this bit should always be
      programmed to 0 by driver software.
      Signed-off-by: NLucas Stach <dev@lynxeye.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      74cd42bc
    • L
      mmc: tegra: implement module external clock change · a8e326a9
      Lucas Stach 提交于
      Allow the the driver to change the clock supplied from the CAR directly,
      minimizing the need to divide the clock inside the SDMMC module itself.
      
      This allows for higher clock speeds than the default 48MHz supplied to
      the module and is a prerequisite to support DDR signaling modes, where
      the Tegra host needs to be run with a fixed internal divider of 2 for
      data to be sampled correctly. (Tegra K1 TRM v03p chapter 29.7.1.1)
      
      Also enable the broken preset value quirk as the preset values need to
      be adapted to the changed clocking. While Tegra114+ allows this through
      vendor registers, there is no such way for Tegra30. Takes the easy way
      out  and keep things consistent between the different SoC generations by
      flagging the preset registers as unusable.
      Signed-off-by: NLucas Stach <dev@lynxeye.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a8e326a9
  15. 22 12月, 2015 2 次提交
  16. 01 4月, 2015 1 次提交
  17. 23 3月, 2015 4 次提交
  18. 29 1月, 2015 1 次提交
  19. 09 9月, 2014 1 次提交
  20. 09 7月, 2014 1 次提交
  21. 23 5月, 2014 2 次提交
  22. 22 5月, 2014 5 次提交
  23. 14 1月, 2014 1 次提交
    • S
      mmc: tegra: add support for Tegra124 · 67debea3
      Stephen Warren 提交于
      Tegra124's MMC controller is very similar to earlier SoC generations,
      and can be supported by the same driver.
      
      However, there are some non-backwards-compatible HW differences, and
      hence a new DT compatible value must be used to describe the HW. This
      patch updates the driver to support that new compatible value.
      
      That said, the HW differences are only relevant when enabling certain
      high-performance transfer modes. Since the driver is currently very
      simple and doesn't enable those modes, we don't actually need to address
      any of these HW differences in the code yet, hence the simple nature of
      this patch.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      67debea3
  24. 27 6月, 2013 1 次提交