From: David Vrabel <david.vrabel@csr.com>
To: Philip Langdale <philipl@overt.org>
Cc: Pierre Ossman <pierre@ossman.eu>,
Ohad Ben-Cohen <ohad@bencohen.org>,
akpm@linux-foundation.org, ian@mnementh.co.uk,
matt@console-pimps.org, roberto.foglietta@gmail.com,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH] sdio: add MMC_CAP_VDD_165_195 host capability
Date: Mon, 12 Oct 2009 14:11:29 +0100 [thread overview]
Message-ID: <4AD32B01.5000600@csr.com> (raw)
In-Reply-To: <20091010114215.5f9d8c94@fido2.homeip.net>
Philip Langdale wrote:
> On Thu, 8 Oct 2009 20:38:26 +0200
> Pierre Ossman <pierre@ossman.eu> wrote:
>
>>> In practice, I expect that the timings are close enough that this
>>> will work anyway, but I think the situation is analogous to HS-MMC
>>> vs HS-SD. There the timings are slightly different and you felt it
>>> was enough to justify a separate host cap for each one.
>>>
>> It's difficult to say without seeing the spec. But if things are not
>> backwards compatible, then we should probably add either a new timing
>> mode, or a new bus mode (where we have open drain and push pull
>> today).
>>
>>> In fact, thinking about it in those terms, it suggests we need to
>>> retroactively introduce a reduced-voltage MMC host flag too, just in
>>> case SDHCI 3.0 controllers barf on those cards...
>>>
>> Maybe. Again, it's difficult to say without seeing the specifics of
>> the new specification.
>
> Make sense. So, I guess the question is do we assume the best case (in
> which case there is no additional work to do - the code that is now
> in allows low voltage SDIO cards to try and run) or the worst case and
> add pre-emptive mode flags?
>
> David, you've actually seen the new spec right? What's your opinion?
In the 3.00 spec, OCR bit 24 is S18R (Signalling 1.8V request). This is
outside of the VDD region (bits 0:23). So I think we can support non
standard DS/HS (Default Speed/High Speed) cards that report 1.8V
operation (in the VDD region) and new UHS-I (Ultra High Speed phase I)
cards without any confusion.
On a UHS-I capable controller, the software would send ACMD41 with S18R
set and see if the card responses with it set. If so, it tells the card
to switch to 1.8V signalling (CMD11) and tells the controller to switch
to 1.8V signalling and SDR12 mode. The controller still supplies 3.3V
to the card even after the switch. Later on the host software will
query the card to find out what UHS-I modes are supported and switch
card and controller to a faster mode (if possible).
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
next prev parent reply other threads:[~2009-10-12 13:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-28 17:51 [PATCH] sdio: add MMC_CAP_VDD_165_195 host capability Ohad Ben-Cohen
2009-09-28 18:09 ` David Vrabel
2009-09-28 20:02 ` Ohad Ben-Cohen
2009-09-29 2:25 ` Philip Langdale
2009-09-29 18:28 ` Pierre Ossman
2009-09-29 20:20 ` Philip Langdale
2009-09-29 21:37 ` Pierre Ossman
2009-09-30 6:10 ` Philip Langdale
2009-10-08 18:38 ` Pierre Ossman
2009-10-10 18:42 ` Philip Langdale
2009-10-12 13:11 ` David Vrabel [this message]
2009-10-13 2:39 ` Philip Langdale
2009-10-14 7:56 ` Ohad Ben-Cohen
2009-10-14 8:48 ` Pierre Ossman
2009-10-14 10:34 ` David Vrabel
2009-10-14 11:05 ` Pierre Ossman
-- strict thread matches above, loose matches on Subject: below --
2009-09-28 17:55 Ohad Ben-Cohen
2009-09-28 17:58 Ohad Ben-Cohen
2009-09-28 18:10 ` Matt Fleming
2009-09-28 20:10 ` Ohad Ben-Cohen
2009-09-28 22:59 ` Andrew Morton
2009-09-29 5:53 ` Matt Fleming
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=4AD32B01.5000600@csr.com \
--to=david.vrabel@csr.com \
--cc=akpm@linux-foundation.org \
--cc=ian@mnementh.co.uk \
--cc=linux-mmc@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=ohad@bencohen.org \
--cc=philipl@overt.org \
--cc=pierre@ossman.eu \
--cc=roberto.foglietta@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox