All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Liu <keyuan.liu@gmail.com>
To: Chris Ball <cjb@laptop.org>
Cc: linux-mmc@vger.kernel.org, pierre@ossman.eu,
	ulf.hansson@linaro.org, zgao6@marvell.com,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	cxie4@marvell.com, Philip Rakity <prakity@nvidia.com>,
	kliu5@marvell.com
Subject: Re: [PATCH v6 11/14] mmc: sdhci: fix the bug that DDR50 can't work for emmc
Date: Tue, 11 Dec 2012 05:48:41 -0500	[thread overview]
Message-ID: <CADz5_gJuwFsUk5rBtd2z2OjOs025W4bsDcJSYrEemuvoUSBWzw@mail.gmail.com> (raw)
In-Reply-To: <CADz5_gLgQ1pT7=X=mDOZyRhpw0rmuMonOr9+Zx_qEc=eZ5jX5w@mail.gmail.com>

2012/12/7 Kevin Liu <keyuan.liu@gmail.com>:
> 2012/12/8 Kevin Liu <keyuan.liu@gmail.com>:
>> 2012/12/8 Chris Ball <cjb@laptop.org>:
>>> Hi,
>>>
>>> On Mon, Nov 19 2012, Kevin Liu wrote:
>>>> In fact, I don't think 3.3v vccq for emmc can work under DDR50 mode
>>>> with SD host.
>>>
>>> I've checked on the scope that we're reaching DDR50 with our 3.3V vccq
>>> eMMC, so it looks like this isn't true.
>>>
>>
>> Chris,
>>
>> Thanks for the check.
>> If you are using sdhci-pxav3.c, 3.3v vccq can work since it enabled
>> the 1.8v signaling in the callback function set_uhs_signaling.
>> What I want to say is if you don't enable the 1.8v signaling bit while
>> using 3.3v vccq, DDR50 on emmc should NOT work. (Use default sdhci
>> code without implementing set_uhs_signaling as the other drivers.)
>> You can just remove the set_uhs_signaling in sdhci-pxav3.c and try again.
>> So we should do this in sdhci.c by default and remove the callback
>> function, which only aim to enabling the 1.8v signaling bit.
>>
>
> Chris,
>
> I would like to say more about my undersanding of 1.8v signaling bit
> and UHS mode select. (Host Control 2 register, offset 0x3E<3:0>)
> According to spec, when 1.8v signaling bit is set, the signaling
> voltage will be changed from 3.3v to 1.8v. But we still provide 3.3v
> vccq in current code. So originally I think it's conflictable in logic
> and we must change to 1.8v vccq. But the fact is both 1.8v and 3.3v
> vccq can work with 1.8v signaling bit set. The reason is below:
> The host controller can't provide and totally control the card power by itself.
> In actual implementation, the card power is supplied by external
> regulator on board (vmmc and vmmcq) rather than host controller. So
> for the 1.8v signaling bit, it will NOT impact signal voltage as spec
> said either. It's just a flag but MUST be checked when UHS-I mode
> selected. That's why we can enable 1.8v signaling bit while using 3.3v
> vccq regulator for emmc DDR50 working. I confirmed this with mmp3 sdh
> owner.
>
> So we just enable the 1.8v signaling bit in host while keep 1.8v or
> 3.3v vccq regulator since emmc support DDR50 with both 1.8v and 3.3v
> vccq. In other words, we make use of the incomplete feature of 1.8v
> signaling bit (not matched with sd host spec that this bit should
> control the signal voltage) to let both 3.3v and 1.8v signaling work
> (well matched with JEDEC spec that DDR50 can work under both 1.8v and
> 3.3v vccq). I think it's good, otherwise only 1.8v can work which make
> things complex and add limitation for board hardware.
>
> So there are below conslusions:
> 1. If card power is supplied by external regulator, then setting 1.8v
> signaling bit with both 1.8v and 3.3v vccq can work for emmc DDR50.
> 2. If host controller provide and totally control the card power, then
> setting 1.8v signaling bit with only 1.8v vccq can work.
> 3. no matter which one of above two, 1.8v signaling bit MUST be set
> for DDR50 working.
> My patch assure item 3 in sdhci.c by default rather than adding
> callback function to do this.
>
> How do you think?
>
Chris,

Hope I'm clear with the 1.8v signaling setting.
So any comments for this patch or the other patches in the same patchset?

Thanks
Kevin

  reply	other threads:[~2012-12-11 10:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-17 11:04 mmc: sdhci: fixes and enhancements Kevin Liu
2012-10-17 11:04 ` [PATCH v6 01/14] mmc: sdhci: fix transfer mode setting bug for cmds w/o data transfer Kevin Liu
2012-10-17 11:04 ` [PATCH v6 02/14] mmc: sdhci: refine voltage support caps setting Kevin Liu
2012-10-17 11:04 ` [PATCH v6 03/14] mmc: sdhci: refine code for sd clock disable/enable in set ios Kevin Liu
2012-10-17 11:04 ` [PATCH v6 04/14] mmc: sdhci: keep the saved clock var up to date Kevin Liu
2012-10-17 11:04 ` [PATCH v6 05/14] mmc: sdhci: fix null return check of regulator_get Kevin Liu
2012-11-05 13:56   ` Chris Ball
2012-11-12  8:57     ` Kevin Liu
2012-11-13  3:00       ` Kevin Liu
2012-11-14  1:49         ` Haojian Zhuang
2012-10-17 11:04 ` [PATCH v6 06/14] mmc: sdhci-pxav3: controller can't get base clock Kevin Liu
2012-11-17 21:57   ` Chris Ball
2012-10-17 11:04 ` [PATCH v6 07/14] mmc: host: adjust uhs timing value Kevin Liu
2012-11-17 22:01   ` Chris Ball
2012-10-17 11:04 ` [PATCH v6 08/14] mmc: sdhci: enhance preset value function Kevin Liu
2012-10-17 11:04 ` [PATCH v6 09/14] mmc: sdhci-pxav3: add quirks2 Kevin Liu
2012-11-17 22:09   ` Chris Ball
2012-11-19  2:34     ` Kevin Liu
2012-11-25 19:26       ` Chris Ball
2012-10-17 11:04 ` [PATCH v6 10/14] mmc: sdhci: introduce signal_voltage_switch callback function Kevin Liu
2012-10-17 11:04 ` [PATCH v6 11/14] mmc: sdhci: fix the bug that DDR50 can't work for emmc Kevin Liu
2012-11-17 22:35   ` Chris Ball
2012-11-19  3:14     ` Kevin Liu
2012-11-19  8:57       ` Kevin Liu
2012-12-07 19:10         ` Chris Ball
2012-12-08  1:54           ` Kevin Liu
2012-12-08  3:14             ` Kevin Liu
2012-12-11 10:48               ` Kevin Liu [this message]
2012-10-17 11:04 ` [PATCH v6 12/14] mmc: sdhci-pxav3: remove set_uhs_signaling function Kevin Liu
2012-11-17 22:39   ` Chris Ball
2012-11-19 11:23     ` Kevin Liu
2012-10-17 11:04 ` [PATCH v6 13/14] mmc: sdhci: solve several vmmc/vqmmc regulator issues Kevin Liu
2012-11-17 23:02   ` Chris Ball
2012-10-17 11:04 ` [PATCH v6 14/14] mmc: sdhci: add function to get retunig timer count Kevin Liu

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=CADz5_gJuwFsUk5rBtd2z2OjOs025W4bsDcJSYrEemuvoUSBWzw@mail.gmail.com \
    --to=keyuan.liu@gmail.com \
    --cc=cjb@laptop.org \
    --cc=cxie4@marvell.com \
    --cc=haojian.zhuang@gmail.com \
    --cc=kliu5@marvell.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=pierre@ossman.eu \
    --cc=prakity@nvidia.com \
    --cc=ulf.hansson@linaro.org \
    --cc=zgao6@marvell.com \
    /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.