LKML Archive on
help / color / mirror / Atom feed
From: David Brownell <>
To: Hans-Peter Nilsson <>
Subject: Re: 2/5: Updates to SPI and mmc_spi: clock with cs inactive, kernel 2.6.19
Date: Thu, 25 Jan 2007 17:28:11 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wednesday 24 January 2007 8:50 pm, Hans-Peter Nilsson wrote:
> There was a comment in the mmc_spi.c glue driver at
> <URL:>:
> +                * some cards seemed happier if they were initialized first
> +                * by the native MMC stack, not SPI ... and in other cases
> +                * rmmod/modprobe of mmc_spi helped the card work better,
> +                * even without power cycling
> +                *
> +                * FIXME find out what that important state is, which is
> +                * not reset here... and makes robustness problems
> I think I've spotted the problem, or at least a problem with a
> solution that fits the description.  What's missing is "at least
> 74 SD clocks to the SD card with keeping CMD line to high. In
> case of SPI mode, CS shall be held to high during 74 clock
> cycles" (from Section 6.4.1, in "Simplified Physical Layer
> Specification 2.0"). ...
> The gotcha is that the SPI framework didn't have a way to
> express transfers with chip-select inactive.  Sure, you can set
> chip-select to inactive for a period of *time*, but never while
> also toggling the clock. 

Actually it _does_ have a way to handle it, if you think about the
problem a bit differently ... focus on high/low, not "inactive":

	spi->mode |= SPI_CS_HIGH;
	// chipselect is now low (conventionally active)

	// ... then high during this next transfer:
	... write 74+ zero bits (10+ bytes)
	// now low again (conventionally "active")

	spi->mode &= ~SPI_CS_HIGH;
	// now high (conventionally "inactive")

That is, for just one one transfer, say the device uses inverse
chipselect polarity:  active-high, not active-low.  Then back to
normal.  Right?  So long as nobody else can access that SPI bus
(the claim/release issue), all should be fine.

That mechanism has been defined for some time, but not widely
implemented; a few chips rquite that semantic for chipselect in
normal operation.

If you agree on this, please update your patch #4 accordingly.
You may need to update your SPI controller driver to handle this
issue too.  (ISTR punting on making the bitbang framework handle
it, but so long as the chipselect is managed with a GPIO this
ought to be almost trivial.)

- Dave

  parent reply	other threads:[~2007-01-26  2:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25  4:50 Hans-Peter Nilsson
2007-01-25 13:05 ` David Brownell
2007-01-26 15:21   ` Hans-Peter Nilsson
2007-01-26 23:31     ` David Brownell
2007-01-26  1:28 ` David Brownell [this message]
2007-01-26 16:01   ` [PATCH] take 2: mmc_spi update, 2.6.19 Hans-Peter Nilsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: 2/5: Updates to SPI and mmc_spi: clock with cs inactive, kernel 2.6.19' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).