linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jh80.chung@samsung.com (Jaehoon Chung)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc
Date: Wed, 27 Aug 2014 12:48:17 +0900	[thread overview]
Message-ID: <53FD5501.1010007@samsung.com> (raw)
In-Reply-To: <CAD=FV=XbV7R+FqRRucA5Cv2A+=3g8zccASwxcTtJD6YyO-ioCg@mail.gmail.com>

Hi, Doug,

On 08/26/2014 12:25 AM, Doug Anderson wrote:
> Jaehoon,
> 
> On Mon, Aug 25, 2014 at 1:50 AM, Jaehoon Chung <jh80.chung@samsung.com> wrote:
>> On 08/25/2014 05:13 PM, Ulf Hansson wrote:
>>> On 22 August 2014 20:27, Sonny Rao <sonnyrao@chromium.org> wrote:
>>>> On Fri, Aug 22, 2014 at 8:31 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>>>>> On 22 August 2014 15:47, Yuvaraj Kumar C D <yuvaraj.cd@gmail.com> wrote:
>>>>>> Exynos 5250 and 5420 based boards uses built-in CD# line for card
>>>>>> detection.But unfortunately CD# line is on the same voltage rails
>>>>>> as of I/O voltage rails. When we cut off vqmmc,the consequent card
>>>>>> detection will break in these boards.
>>
>> I didn't know that use CD# line for card detect.
>> And if CD# voltage rails and I/O voltage rail are same voltage, it doesn't make sense.
>> Which card is used with same voltages? (eMMC? SD? SDIO?)
>>
>> Well, I have checked Exynos5250 and 5420, but it looks like not same rails.
> 
> I'm not sure I totally understood what you said.  In my manual I have
> a table titled "Table 2-1 Exynos 5420 Pin List".  Look in this table
> for XMMC2CDN and XMMC2DATA_0.  Look to the right of the table and
> you'll see the power domain.  For both it shows VDDQ_MMC2.  If that
> doesn't mean that the two are in the same voltage domain then I don't
> know what does.  Can you point to any examples where they have
> different voltage domains?
I think you're mis-understanding for it.
Right, It's described at exynos5420, but it's not connected.
Exynos4 series are also described, but we used the broken card detection scheme and power used one of "always-on" powers.
Because Card-detection rail need to enable as "always-on".

We don't need to consider this. I checked the circuit, this patch didn't need.

exynos5 also used the gpio-pin for card-detection. And we can use the slot-gpio API.

Best Regards,
Jaehoon Chung

> 
> I agree that what exynos does is not sensible, but that's what it is.
> 
> 
>>>>> I am not sure I follow here.
>>>>>
>>>>> Is the card detect mechanism handled internally by the dw_mmc controller?
>>>>
>>>> Yes
>>
>> What card detect mechanism?
> 
> The dw_mmc controller has a way to read the card detect, right?
> That's internal to the controller.  The alternative would be to use a
> generic GPIO for card detect.
> 

  reply	other threads:[~2014-08-27  3:48 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-22 13:47 [PATCH V2 0/3] Adding UHS support for dw_mmc driver Yuvaraj Kumar C D
2014-08-22 13:47 ` [PATCH V2 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators Yuvaraj Kumar C D
2014-08-25 12:32   ` Jaehoon Chung
2014-08-25 15:06     ` Doug Anderson
2014-08-29 11:34   ` Ulf Hansson
2014-09-29 12:31     ` Bartlomiej Zolnierkiewicz
2014-09-30  5:23       ` Jaehoon Chung
2014-10-01 13:57         ` Bartlomiej Zolnierkiewicz
2014-10-01 14:14           ` Bartlomiej Zolnierkiewicz
2014-09-30 17:22       ` Doug Anderson
2014-10-01 13:06         ` Bartlomiej Zolnierkiewicz
2014-10-01 15:38           ` Doug Anderson
2014-08-22 13:47 ` [PATCH V2 2/3] mmc: dw_mmc: Support voltage changes Yuvaraj Kumar C D
2014-08-22 15:35   ` Ulf Hansson
2014-08-22 20:38     ` Doug Anderson
2014-08-25  8:31       ` Ulf Hansson
2014-08-25 20:59         ` Doug Anderson
2014-08-29 11:43           ` Ulf Hansson
2014-09-29 12:49             ` Bartlomiej Zolnierkiewicz
2014-08-22 13:47 ` [PATCH V2 3/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc Yuvaraj Kumar C D
2014-08-22 15:31   ` Ulf Hansson
2014-08-22 18:27     ` Sonny Rao
2014-08-25  8:13       ` Ulf Hansson
2014-08-25  8:50         ` Jaehoon Chung
2014-08-25 15:25           ` Doug Anderson
2014-08-27  3:48             ` Jaehoon Chung [this message]
2014-08-27  4:14               ` Doug Anderson
2014-08-27  4:47                 ` Jaehoon Chung
2014-08-27 15:49                   ` Doug Anderson
2014-08-28  4:54                     ` Yuvaraj Kumar
2014-08-28  8:43                     ` Jaehoon Chung
2014-08-28 15:52                       ` Doug Anderson
2014-08-25 15:20         ` Doug Anderson
2014-08-26  7:37           ` Ulf Hansson
2014-08-26 20:32             ` Doug Anderson
2014-08-27 11:17               ` Ulf Hansson
2014-08-27 11:20                 ` Ulf Hansson
2014-08-27 15:52                 ` Doug Anderson
2014-08-28  7:25                   ` Ulf Hansson
2014-08-28 15:50                     ` Doug Anderson
2014-08-28 17:50                       ` Sonny Rao
2014-08-29  4:08                         ` Doug Anderson
2014-08-27  3:55           ` Jaehoon Chung

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=53FD5501.1010007@samsung.com \
    --to=jh80.chung@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).