On Wed, 1 Aug 2007 10:02:28 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 01 August 2007, Pierre Ossman wrote:
> >
> > Well, it's rather straight-forward if you think about it. As they've
> > changed the addressing scheme,
>
> Since I've not seen the MMC4 spec, I couldn't know. :)
>
You can see the same thing in SD with the if cond thingy.
> And the nearest approximation of MMC4 I've got (an early Samsung
> spec) says CMD58 has argument "none" (== 0) ... while one of the
> cards I've got rejected CMD58 before CMD1. So "straightforward"
> is not a word I could apply here...
>
We can just code it so that failure is acceptable for that initial
CMD58.
>
> > but retain the original commands, a host
> > that does not understand the new scheme would utterly destroy the
> > data. So the card refuses to init unless the host can present some
> > evidence that it understands the new scheme.
>
> Right, but that doesn't answer my question: whether the card
> is specified to lock up "forever", or whether (as I'd expect)
> reinitialization (starting with reset) works the normal way.
>
Like SDHC, it never goes out of idle mode.
>
> My current setup uses a breadboard, so it can hook up to the
> real SPI hardware ... I started out using bitbanged SPI to a
> card which normally muxed to a "native" controller. Maybe
> one of those could work for you.
>
Well, I'd need something to do the banging.
>
> > Please add a comment that we know that MMC 4.2 is broken and can be
> > fixed once someone is able to test.
>
> Doesn't the general disclaimer that MMC4 cards haven't been
> tested already cover that part? If you like, just tweak the
> patch comments to clarify.
>
The disclaimer is in the commit message. And people rarely go digging
into the history for documentation.
I'll add the comment before committing.
>
> So, move the param and mmc_spi_set_crc() into core.c then, and
> leave the calls where they are?
>
mmc_spi_set_crc() fits quite nicely into mmc_ops.c, so no need for
moving that. I was thinking more along the lines of:
extern int mmc_spi_crc_enabled;
mmc_spi_set_crc(host, mmc_spi_crc_enabled);
> Can we do that as a separate patch? You said below we can proceed,
> which suggests to me that now's the time to convert to incrmentals.
> I don't mind a few more update patches, but it'd be easier to do
> them against say a git-mmc patch against 2.6.23-rc2 ...
>
Sure.
> >
> > I hate this part of the spec. The SD spec also claims:
> >
> > "Clear condition B: Always related to the previous command"
> >
> > But in the SPI section, they back out of that claim. So for SPI,
> > things seems somewhat sane.
>
> I don't have either of those specs. "Previous command" isn't
> particularly clear, though maybe in context it could be ... it
> might mean the immediately preceding command, or the one before
> that, depending on usage.
>
That's from the public SD physical spec. And the wording doesn't get
much clearer. Sometimes they also talk about the "last" command, which
is equally ambiguous.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
