All of lore.kernel.org
 help / color / mirror / Atom feed
From: Holger Schurig <holgerschurig@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-mmc <linux-mmc@vger.kernel.org>
Subject: Re: BUG 4.4rc-4: wrong eMMC signaling voltage reported
Date: Tue, 22 Dec 2015 09:33:21 +0100	[thread overview]
Message-ID: <87poxyrige.fsf@gmail.com> (raw)
In-Reply-To: <CAPDyKFoQqQFmPwrnCeJBcz=mnzW8zbWb5i7bc64oo7bN_113zQ@mail.gmail.com>


> The no-1-8-v is a somewhat broken DT binding. I advise people to not
> use any more.
> Depending on the sdhci variant it have different meanings.
>
> I guess you are using the sdhci-esdhc-imx variant, which means
> no-1-8-v will disable UHS modes for SD-cards (those requiring 1.8V
> signal voltage). It has no impact on (e)MMC.

Correct, I'm on i.MX6 and using sdhci-esdhc-imx.


> As the host driver announces support for MMC_CAP_1_8V_DDR, that's what
> the mmc core will try to use. Actually the mmc core will first try
> 1.8V and if it fails, go for 3.3V.
>
> Likely, sdhci_do_start_signal_voltage_switch() will success to write
> the corresponding registers to change the signal voltage to 1.8V,
> which makes the mmc core believe it was a success.
>
> *If* your statement around that your HW don't support 1.8V signal
> voltage, we should perhaps add new mmc cap as currently we don't have
> a "MMC_CAP_3_3V_DDR". Although, you need to convince on that, because
> my experience tells that quite many has misunderstood the HW design in
> this regard.

The hardware guys told me that the eMMC chip get's its power from the
i.MX6, there are connections NVCC_SD1...NVCC_SD3 which are directly
connected to 3V3, not to some PMIC. When I read the docs correctly, this
means that the SDHCI related I/O lines of the i.MX6 are therefore tied
to 3.3V only, because of this NVCC_SDx power domain.

And on the eMMC schematic page, the signals VCC and VCCQ ("DQ Power") of
the eMMC are also tied directly to 3.3V.

Therefore I assume that the hardware itself cannot provide 1.8V and I
added this "knowledge" to the Device Tree.




Two questions:

* should I propose a patch that reads theno-1-8-v setting from DT and
removes the announcement of MMC_CAP_1_8V_DDR ?

* isn't MMC_CAP_3_3V_DDR superfluous, because it must any implementation
must support 3.3V (I'm not too much into the standard ...).


  reply	other threads:[~2015-12-22  8:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 14:53 BUG 4.4rc-4: wrong eMMC signaling voltage reported Holger Schurig
2015-12-17 16:10 ` Ulf Hansson
2015-12-22  8:33   ` Holger Schurig [this message]
2015-12-22  9:18     ` Ulf Hansson
2015-12-22  9:39   ` Fabio Estevam
2015-12-22 10:28     ` Ulf Hansson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87poxyrige.fsf@gmail.com \
    --to=holgerschurig@gmail.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.