On Tue, 29 Sep 2009 23:10:13 -0700
Philip Langdale <philipl@xxxxxxxxx> wrote:
> On Tue, 29 Sep 2009 23:37:32 +0200
> Pierre Ossman <pierre@xxxxxxxxx> 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:
signature.asc
Description: PGP signature
