1. 15 4月, 2019 4 次提交
    • S
      mmc: tegra: fix CQE enable and resume sequence · b7754428
      Sowjanya Komatineni 提交于
      Tegra CQHCI/SDHCI design prevents write access to SDHCI block size
      register when CQE is enabled and unhalted.
      
      CQHCI driver enables CQE prior to invoking sdhci_cqe_enable which
      violates this Tegra specific host requirement.
      
      This patch fixes this by configuring sdhci block registers prior
      to CQE unhalt.
      
      This patch also has a fix for retry of unhalt due to known Tegra
      specific CQE resume bug where first unhalt might not succeed when
      clear all tasks is performed prior to resume and need a second unhalt.
      
      This patch also includes CQE enable fix for CMD CRC errors that
      happen with the specific sandisk emmc device when status command
      is sent during the transfer of last data block due to marginal timing.
      Tested-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b7754428
    • S
      mmc: tegra: add Tegra186 WAR for CQE · c6e7ab90
      Sowjanya Komatineni 提交于
      Tegra186 CQHCI host has a known bug where CQHCI controller selects
      DATA_PRESENT_SELECT bit to 1 for DCMDs with R1B response type and
      since DCMD does not trigger any data transfer, DCMD task complete
      happens leaving the DATA FSM of host controller in wait state for
      the data.
      
      This effects the data transfer tasks issued after the DCMDs with
      R1b response type resulting in timeout.
      
      SW WAR is to set CMD_TIMING to 1 in DCMD task descriptor. This bug
      and SW WAR is applicable only for Tegra186 and not for Tegra194.
      
      This patch implements this WAR thru NVQUIRK_CQHCI_DCMD_R1B_CMD_TIMING
      for Tegra186 and also implements update_dcmd_desc of cqhci_host_ops
      interface to set CMD_TIMING bit depending on the NVQUIRK.
      Tested-by: NJon Hunter <jonathanh@nvidia.com>
      Reviewed-by: NRitesh Harjani <riteshh@codeaurora.org>
      Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c6e7ab90
    • S
      mmc: tegra: update hw tuning process · ea8fc595
      Sowjanya Komatineni 提交于
      This patch includes below HW tuning related fixes.
          configures tuning parameters as per Tegra TRM
          WAR fix for manual tap change
          HW auto-tuning post process
      
      As per Tegra TRM, SDR50 mode tuning execution takes upto maximum
      of 256 tuning iterations and SDR104/HS200/HS400 modes tuning
      execution takes upto maximum of 128 tuning iterations.
      
      This patch programs tuning control register with maximum tuning
      iterations needed based on the timing along with the start tap,
      multiplier, and step size used by the HW tuning.
      
      Tegra210 has a known issue of glitch on trimmer output when the
      tap value is changed with the trimmer input clock running and the
      WAR is to disable card clock before sending tuning command and
      after sending tuning command wait for 1usec and issue SW reset
      followed by enabling card clock.
      
      This WAR is applicable when changing tap value manually as well.
      Tegra SDHCI driver has this implemented correctly for manual tap
      change but missing SW reset before enabling card clock during
      sending tuning command.
      
      Issuing SW reset during tuning command as a part of WAR and is
      applicable in cases where tuning is performed with single step size
      for more iterations. This patch includes this fix.
      
      HW auto-tuning finds the best largest passing window and sets the
      tap at the middle of the window. With some devices like sandisk
      eMMC driving fast edges and due to high tap to tap delay in the
      Tegra chipset, auto-tuning does not detect falling tap between the
      valid windows resulting in a parital window or a merged window and
      the best tap is set at the signal transition which is actually the
      worst tap location.
      
      Recommended SW solution is to detect if the best passing window
      picked by the HW tuning is a partial or a merged window based on
      min and max tap delays found from chip characterization across
      PVT and perform tuning correction to pick the best tap.
      
      This patch has implementation of this post HW tuning process for
      the tegra hosts that support HW tuning through the callback function
      tegra_sdhci_execute_hw_tuning and uses the tuned tap delay.
      Tested-by: NJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ea8fc595
    • S
      mmc: tegra: fix ddr signaling for non-ddr modes · 92cd1667
      Sowjanya Komatineni 提交于
      ddr_signaling is set to true for DDR50 and DDR52 modes but is
      not set back to false for other modes. This programs incorrect
      host clock when mode change happens from DDR52/DDR50 to other
      SDR or HS modes like incase of mmc_retune where it switches
      from HS400 to HS DDR and then from HS DDR to HS mode and then
      to HS200.
      
      This patch fixes the ddr_signaling to set properly for non DDR
      modes.
      Tested-by: NJon Hunter <jonathanh@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
      Cc: stable@vger.kernel.org # v4.20 +
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      92cd1667
  2. 25 2月, 2019 3 次提交
  3. 17 12月, 2018 1 次提交
  4. 08 10月, 2018 22 次提交
  5. 30 7月, 2018 1 次提交
  6. 16 7月, 2018 5 次提交
    • A
      mmc: tegra: Add and use tegra_sdhci_get_max_clock() · 44350993
      Aapo Vienamo 提交于
      Implement and use tegra_sdhci_get_max_clock() which returns the true
      maximum host clock rate. The issue with tegra_sdhci_get_max_clock() is
      that it returns the current clock rate of the host instead of the
      maximum one, which can lead to unnecessarily small clock rates.
      
      This differs from the previous implementation of
      tegra_sdhci_get_max_clock() in that it doesn't divide the result by two.
      Signed-off-by: NAapo Vienamo <avienamo@nvidia.com>
      Tested-by: NMarcel Ziswiler <marcel.ziswiler@toradex.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      44350993
    • S
      mmc: tegra: prevent ACMD23 on Tegra 3 · 726df1d5
      Stefan Agner 提交于
      It seems that SD3.0 advertisement needs to be set for higher eMMC
      speed modes (namely DDR52) as well. The TRM states that the SD3.0
      advertisement bit should be set for all controller instances, even
      for those not supporting UHS-I mode...
      
      When specifying vqmmc-supply as a fixed 1.8V regulator on a Tegra
      SD/MMC instance which is connected to a eMMC device, the stack
      enables SD3.0. However, enabling it has consequences: If SDHCI 3.0
      support is advertised the stack enables Auto-CMD23. Unfortunately
      Auto-CMD23 seems not to work well with Tegra 3 currently. It leads
      to regular warnings:
        mmc2: Got command interrupt 0x00010000 even though no command operation was in progress.
      
      It is not entirely clear why those errors happens. It seems that
      a Linux 3.1 based downstream kernel which has Auto-CMD23 support
      does not show those warnings.
      
      Use quirk SDHCI_QUIRK2_ACMD23_BROKEN to prevent Auto-CMD23 being
      used for now. With this the eMMC works stable on high-speed mode
      while still announcing SD3.0.
      
      This allows to use mmc-ddr-1_8v to enables DDR52 mode. In DDR52
      mode read speed improves from about 42MiB/s to 72MiB/s on an
      Apalis T30.
      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>
      726df1d5
    • S
      mmc: tegra: fix eMMC DDR52 mode · e300149e
      Stefan Agner 提交于
      Make sure the clock is doubled when using eMMC DDR52 mode.
      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>
      e300149e
    • 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
  7. 08 5月, 2018 1 次提交
  8. 30 10月, 2017 1 次提交
  9. 30 8月, 2017 2 次提交