Re: [PATCH] sdio: add MMC_CAP_VDD_165_195 host capability

[Pierre Ossman <pierre@ossman.eu>]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

On Tue, 29 Sep 2009 23:10:13 -0700
Philip Langdale <philipl@overt.org> wrote:

> On Tue, 29 Sep 2009 23:37:32 +0200
> Pierre Ossman <pierre@ossman.eu> wrote:
> 
> > I must have missed that part of discussion. If the voltage fully
> > overlaps with the MMC definition, then I don't see the controllers
> > having to be designed explicitly for SD 3.0. If not, then we probably
> > need a new voltage bit for the hosts. In that case separating
> > supporting from non-supporting should sort itself out easily.
> 
> The reason I think we need is a host cap is that low voltage operations
> apparently implies different signal timings. This is second hand from
> David as there are no public specs for 3.0 available yet. So, the
> failure case is a controller that publishes support for low voltage,
> but only expects MMC cards to use it.
> 
> 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.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]