All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhangfei gao <zhangfei.gao@gmail.com>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Daniel Drake <dsd@laptop.org>,
	linux-mmc@vger.kernel.org, Mike Rapoport <mike@compulab.co.il>,
	Zhangfei Gao <zhangfei.gao@marvell.com>,
	Bing Zhao <bzhao@marvell.com>
Subject: Re: MMC runtime PM patches break libertas probe
Date: Mon, 30 May 2011 07:04:20 -0400	[thread overview]
Message-ID: <BANLkTimuLrCd3oHeWOC73scuQ6ydvuwpvw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTi=o6Hgb=icinjmZqVx09dx+cp-enw@mail.gmail.com>

On Mon, May 30, 2011 at 3:32 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Mon, May 30, 2011 at 10:01 AM, Daniel Drake <dsd@laptop.org> wrote:
>> On 30 May 2011 07:52, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>>> Last we talked, we found out runtime PM didn't work because the sd8686
>>> required an additional manipulation of an external reset gpio line,
>>> and that the only reason OLPC could power it down/up was this patch:
>>>
>>> http://dev.laptop.org/git/olpc-2.6/commit/?h=olpc-2.6.35&id=e9bee721fb0cc303286d1fe5df4930ce79b0b1e0
>>
>> My further investigation here suggests that this change is not
>> necessary. It was added in response to a separate (hard-to-reproduce)
>> issue and it was never known if it would actually fix that issue, it
>> was more of a guess. We don't have any convincing evidence that it
>> helps, so it will be dropped in future.
>>
>> Anyway, just to be sure, I tried combining this hack with runtime PM,
>> and also as a regulator, and it didn't help anything. runtime PM still
>> fails to power up the card.
>>
>> Sorry for leading you down the wrong path there.
> ...
>>> does mmc_stop_host+mmc_start_host
>>> work for you without manipulating that reset gpio ?
>>
>> Yes.
>
> Hm. I still don't entirely get it, because we had others (Mike, cc'd)
> saying too that the sd8686 requires manipulating an external reset
> gpio after bringing the power back up.

sd8686 requires two pins to control power, PDn and RESETn.
To enable sd8686, PDn and RESETn should both set high.
To disable sd8686, PDn should be set low.
We also have plans to use runtime PM to optimize these two pins,
suggested by Ohad before.
However currently we still use rfkill method to control the two pins.
In the stress test, we found wlan card may not be probed successfully
even the two pins are set correctly, so we manually detect whether
mmc->card is allocated or not, not sure whether runtime PM to handle
this case.

>
> Maybe someone from Marvell can comment on this (cc'ing Zhangfei Gao) ?
>
>> You didn't comment on the added mmc_select_voltage() call. Is that one
>> also sensible?
>
> I guess. if we're reading the I/O OCR, might as well use it. This way
> our runtime PM power up path will also be identical to the one induced
> by mmc_attach_sdio.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2011-05-30 11:04 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-31 14:29 MMC runtime PM patches break libertas probe Daniel Drake
2010-10-31 14:42 ` Ohad Ben-Cohen
2010-10-31 14:55   ` Daniel Drake
2010-10-31 15:08     ` Ohad Ben-Cohen
2010-10-31 15:10       ` Daniel Drake
2010-10-31 15:16         ` Ohad Ben-Cohen
2010-10-31 15:21           ` Daniel Drake
2010-10-31 15:21           ` Daniel Drake
2010-10-31 15:27             ` Ohad Ben-Cohen
2010-10-31 15:57               ` Daniel Drake
2010-10-31 16:16                 ` Ohad Ben-Cohen
2010-10-31 16:24                   ` Daniel Drake
2010-10-31 19:06                     ` Ohad Ben-Cohen
2010-11-01  8:27                       ` Ohad Ben-Cohen
2010-11-06 21:19                         ` Daniel Drake
2010-11-07  1:48                           ` Nicolas Pitre
2010-11-07 10:19                             ` Daniel Drake
2010-11-07 15:12                               ` Nicolas Pitre
2010-11-07 10:42                           ` Ohad Ben-Cohen
2010-11-07 10:51                             ` Daniel Drake
2010-11-07 13:17                               ` Ohad Ben-Cohen
2010-11-16 13:22                         ` Ohad Ben-Cohen
2010-11-16 14:29                           ` Daniel Drake
2010-11-16 14:49                             ` Ohad Ben-Cohen
2010-11-17  6:46                               ` Mike Rapoport
2010-11-17  7:29                                 ` Ohad Ben-Cohen
2010-11-17 14:54                                   ` Nicolas Pitre
2010-11-16 17:17                           ` Arnd Hannemann
2010-11-16 20:58                             ` Ohad Ben-Cohen
2010-11-16 21:16                               ` Arnd Hannemann
2010-11-16 22:26                                 ` Ohad Ben-Cohen
2011-05-29 16:21                       ` Daniel Drake
2011-05-30  6:52                         ` Ohad Ben-Cohen
2011-05-30  7:01                           ` Daniel Drake
2011-05-30  7:32                             ` Ohad Ben-Cohen
2011-05-30 11:04                               ` zhangfei gao [this message]
2011-05-30 11:16                                 ` Ohad Ben-Cohen
2011-06-02  8:39                                   ` Bing Zhao
2011-06-02 18:25                                     ` Ohad Ben-Cohen
2011-06-03 22:28                                       ` Bing Zhao
2011-06-03 22:52                                         ` Ohad Ben-Cohen
2011-06-07 14:34                                           ` Arnd Hannemann
2011-06-07 14:45                                             ` Ohad Ben-Cohen
2011-06-08 14:34                                           ` Ohad Ben-Cohen
2011-06-10  2:02                                             ` zhangfei gao
2011-06-10  4:28                                               ` Ohad Ben-Cohen
2011-06-11  2:33                                                 ` zhangfei gao
2011-06-11  9:03                                                   ` Ohad Ben-Cohen

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=BANLkTimuLrCd3oHeWOC73scuQ6ydvuwpvw@mail.gmail.com \
    --to=zhangfei.gao@gmail.com \
    --cc=bzhao@marvell.com \
    --cc=dsd@laptop.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mike@compulab.co.il \
    --cc=ohad@wizery.com \
    --cc=zhangfei.gao@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.