Re: SD response type 6 vs. 1

[Pierre Ossman <drzeus-list@drzeus.cx>]

andrzej zaborowski wrote:
> Hi,
>  Linux has the same values for MMC_RSP_R1 and MMC_RSP_R6 thus making
> the two response formats indistinguishable for mmc/sd hosts. Hardware
> like my OMAP310 needs to know exactly whether to expect an R1 or R6
> format, otherwise CMD3 fails.
>
> Sure it would be nice if it didn't care, but nevertheless, it's not a
> hardware bug - the two formats are specified separately in SD specs
> because they *are* different. So the hardware has full right to know
> the right response type. Rather it's a hack to rely on R1 and R6
> having the same size, like Linux does now. It would also be a hack to
> allow the CMD3 to fail with CRC error and ignore the error, like
> omap.c did before, because it makes an assumption that's not in the
> OMAP specs.

If you're referring to CERR, then I suggest you reread the specs. They
even explicitly say its okay to ignore it.

Anyway, I'm not going into this discussion again without a valid
argument as to why the suggest path won't work.

>
> The following is an ugly fix. It's ugly because host code should be
> agnostic to opcodes, as mentioned by Pierre Ossman.
> I believe this was already submitted by Carlos Aguiar and rejected by
> Pierre, which resulted in leaving the driver broken on some boards.

This just hides the fact that the host parses the data more than we want
and expect it to do.

>
> A more correct and more intrusive fix would look like this:

Afraid not. The response type specifies format, not semantical contents.

The correct fix has already been discussed, but I have seen zero
attempts at implementing it:

http://linux.omap.com/pipermail/linux-omap-open-source/2007-April/009500.html

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org