Re: [patch 2.6.22-git5 3/4] MMC core learns about SPI

[Pierre Ossman <drzeus-mmc-p3sGCRWkH8CeZLLa646FqQ@public.gmane.org>]

On Wed, 1 Aug 2007 10:02:28 -0700
David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 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/