Drive uSDHC I/O at 1V8 on Linux 3.14.52

[raulbenetballes]

Hi,

our custom board uses 1V8 IOs for our eMMC (on uSDHC2) and WiFi module (on uSDHC3), around a i.MX6SL.

We just realized that the mmc linux driver on 3.14.52 sets the I/O to 3V3 per default, and only changes it to 1V8 under some very specific circumstances (e.g.; high speed DDR mode). As those circumstances do not apply in our case, the interfaces are being setup to 3V3. (so far, we were relying on setting the I/O levels on the DTS, but had completely missed the fact that VSELECT overrules that)

Does anybody know of a good and maintainable solution to this ?

Our current plan is to 'hack' the driver to force it to do the right thing, but that is always problematic when upgrading kernels and the like.

We have observed that kernel 3.16 (in core/mmc.c power_up()) adds some extra code that attempts to automatic select the right voltage based on the restrictions of the 'regulator' , but I haven't managed to get a viable solution for defining the regulator in the dts that has the behaviour ? (anybody had any advise on that).

Regards,

Raul

[Yuri]

Hello,

  General considerations are as following. The i.MX6 SL has two voltage suppliers : NVCC33_IO and NVCC18_IO. The bit LVE in corresponding Pad Control Register defines what voltage will be applied to the pin. Default value VLE=0 means 3.3V.

  The i.MX6 SL has special recommendations, when using so called low voltage design, in particular it relates to 1.8V SD cards. Please refer to section 7.2.4 (Power-up sequence in low voltage system design) of the “Hardware Development Guide for i.MX 6SoloLite - User Guide”

http://cache.freescale.com/files/32bit/doc/user_guide/IMX6SLHDG.pdf

  Also, from the following (internal) thread  i.MX6SL : power up sequence for NVCC33_IO 

  In MX6SL, the I/O Gate Keeper circuit is enabled and is powered by NVCC33_IO (LVE bit is "0") by default.

There is a "potential" issue if the following conditions are matched in customer's design.

1. A MX6SL I/O is connected to external chip with 1.8V powered I/O AND

2. No 47k ohm (or smaller resistance) pull-low resistor on that I/O

If both the above two conditions are matched, the I/O pin voltage may kick-up to ~2V before setting the LVE bit to "1" in U-boot.

Thus the following guidelines should be followed -

1. Add 47k (or smaller) pull-low resistors on all 1.8V I/Os

2. Power the external chip 1.8V I/O supply using NVCC18_IO to make sure both MX6SL and external chip I/O supplies would be turned-on at the same time.

As for Linux support :

1.

in DTS file, for 1.8V only, please remove no-1-8-v.

2.

  Below is Community thread, where two (hope, useful) patches may be found.

How to configure mmc/sdio 1.8v on imx6 linux 3.10.17 BSP

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[raulbenetballes]

Yuri,

in the i.MX6SL changing the value of the VSELECT bit of register uSDHCx_VEND_SPEC, changes the I/O voltage of that particular uSDHCx interface, regardless of the LV setting.

This is not clear in the documentation, but I have found out by writting to it.

If I write 1, then SD_CLK goes to 1.8V. (SD_CLK is the only signal I can probe in my design with oscilloscope)

If I write 0, then SD_CLK goes to 3.3V.

That is whilst LV=1.

This is consistent with the SD Driver code in the Linux Kernel. Depending on the selected voltage rail, it sets the VSELECT accordignly.

My issue is that the driver on 3.14.52 has no provision for driving the eMMC at 1.8V _all_the_time_.

Regards,

Raul

[Yuri]

Hello,

yes, "If a pin is set to a uSDHC mode in the MUXCTL register, then the LVE field of the PAD Settings
register is ignored. The single register field that controls the voltage settings for the i.MX6SL processor

pads and the external card pads is the VSELECT field in register uSDHCx_VEND_SPEC."

Regards,

Yuri.