1. 07 Jul, 2020 1 commit
  2. 27 Jun, 2020 2 commits
  3. 24 Jun, 2020 2 commits
    • Haibo Chen's avatar
      mmc: fsl_esdhc_imx: disable the CMD CRC check for standard tuning · ba61676f
      Haibo Chen authored and Peng Fan's avatar Peng Fan committed
      
      
      In current code, we add 1ms dealy after each tuning command for standard
      tuning method. Adding this 1ms dealy is because USDHC default check the
      CMD CRC and DATA line. If detect the CMD CRC, USDHC standard tuning
      IC logic do not wait for the tuning data sending out by the card, trigger
      the buffer read ready interrupt immediately, and step to next cycle. So
      when next time the new tuning command send out by USDHC, card may still
      not send out the tuning data of the upper command,then some eMMC cards
      may stuck, can't response to any command, block the whole tuning procedure.
      
      If do not check the CMD CRC for tuning, then do not has this issue. USDHC
      will wait for the tuning data of each tuning command and check them. If the
      tuning data pass the check, it also means the CMD line also okay for tuning.
      
      So this patch disable the CMD CRC check for tuning, save some time for the
      whole tuning procedure.
      Signed-off-by: default avatarHaibo Chen <haibo.chen@nxp.com>
      ba61676f
    • Haibo Chen's avatar
      mmc: fsl_esdhc_imx: fix the mask for tuning start point · 135c10a7
      Haibo Chen authored and Peng Fan's avatar Peng Fan committed
      According the RM, the bit[6~0] of register ESDHC_TUNING_CTRL is
      TUNING_START_TAP, bit[7] of this register is to disable the command
      CRC check for standard tuning. So fix it here.
      
      Fixes: fa33d207
      
       ("mmc: split fsl_esdhc driver for i.MX")
      Signed-off-by: default avatarHaibo Chen <haibo.chen@nxp.com>
      135c10a7
  4. 23 Jun, 2020 2 commits
  5. 22 Jun, 2020 10 commits
  6. 18 Jun, 2020 4 commits
  7. 15 Jun, 2020 1 commit
    • Yangbo Lu's avatar
      mmc: fsl_esdhc: workaround for hardware 3.3v IO reliability issue · c927d658
      Yangbo Lu authored and Peng Fan's avatar Peng Fan committed
      
      
      When eSDHC operates at 3.3v, damage can accumulate in an internal
      level shifter at a higher than expected rate. The faster the interface
      runs, the more damage accumulates. This issue now is found on LX2160A
      eSDHC1 for only SD card.
      
      The hardware workaround is recommended to use an on-board level shifter
      that is 1.8v on SoC side and 3.3v on SD card side.
      
      For boards without hardware workaround, this option could be enabled,
      ensuring 1.8v IO voltage and disabling eSDHC if no card.
      This option assumes no hotplug, and u-boot has to make all the way to
      to linux to use 1.8v UHS-I speed mode if has card.
      If you do not want the workaround for better user experience, of course
      you can choose to not select it running eSDHC in unsafe mode.
      Signed-off-by: default avatarYangbo Lu <yangbo.lu@nxp.com>
      Acked-by: Peng Fan's avatarPeng Fan <peng.fan@nxp.com>
      c927d658
  8. 14 Jun, 2020 1 commit
  9. 11 Jun, 2020 4 commits
  10. 08 Jun, 2020 2 commits
  11. 07 Jun, 2020 2 commits
  12. 04 Jun, 2020 9 commits