From: Arnd Bergmann <arnd@arndb.de>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
Chris Ball <cjb@laptop.org>, Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH/RFC] mmc: add DT bindings for more MMC capability flags
Date: Wed, 6 Feb 2013 22:00:35 +0000 [thread overview]
Message-ID: <201302062200.35499.arnd@arndb.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1302061817120.13474@axis700.grange>
On Wednesday 06 February 2013, Guennadi Liakhovetski wrote:
>
> On Thu, 7 Feb 2013, Arnd Bergmann wrote:
>
> > On Wednesday 06 February 2013 17:25:42 Guennadi Liakhovetski wrote:
> > >
> > > Thank for pointing me out at that thread. However, I don't think
> > > MMC_CAP_POWER_OFF_CARD has anything to do with compatibility or hardware
> > > revisions. At least I haven't yet come across any sd/mmc hosts, that also
> > > supply card power. You could "derive" this flag from the presence of a
> > > regulator, capable of changing its status (switching on / off), but even
> > > then you're not guaranteed, that you actually can (and want to) power the
> > > card off at run-time - the regulator can be shared etc. So, an explicit
> > > flag is needed.
> >
> > It sounds like something that should be handled in a controller specific
> > way I think. E.g. on SDHCI, there seems to always be a method to power
> > down the card using the SDHCI_POWER_CONTROL register, even without
> > any external regulators.
>
> If I understand correctly, that register only controls card bus power.
> Further sdhci.c uses regulators (host->vmmc) to power up and down the
> card.
Ok, that may be true. So a device that can only power down the bus
but not the card itself should not set MMC_CAP_POWER_OFF_CARD
then? I only saw that it is set unconditionally for the PCI
case, which does not use regulators.
Arnd
prev parent reply other threads:[~2013-02-06 22:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 16:45 [PATCH/RFC] mmc: add DT bindings for more MMC capability flags Guennadi Liakhovetski
2013-02-06 15:15 ` Mark Rutland
2013-02-06 16:25 ` Guennadi Liakhovetski
2013-02-07 0:44 ` Arnd Bergmann
2013-02-06 17:32 ` Guennadi Liakhovetski
2013-02-06 22:00 ` Arnd Bergmann [this message]
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=201302062200.35499.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=cjb@laptop.org \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=g.liakhovetski@gmx.de \
--cc=linux-mmc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mark.rutland@arm.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.