On Monday 23 July 2007, Anton Vorontsov wrote: > On Thu, Jul 19, 2007 at 01:28:17PM -0700, David Brownell wrote:
> > I notice that driver disregards the cs_change instructions in the > > messages ... I could imagine how that could make a big difference. For example, the extra flapping on the chipselect changes timings... > > If that hardware were doing the right thing, then it would work > > reliably! Since it's not reliable, it's doing something wrong. > > You seem to think it's not a hardware issue; that may be true. > > > > Recall that the first dozen or so commands worked just fine. The > > issue was that some byte that should have been all-ones or 0xfe > > reported instead an 0xf8. That's not the kind of error that can > > be explained by clock skew; it covers at least two bits. > > Yup, I've either noticed that 0xf8 and 0xfe differs by only two > bits (and by three if comparing to 0xff). But I can't really > explain it yet. See if fixing the cs_change handling -- so that chipselect never goes inactive except between MMC requests -- helps. Minimally, you'll notice that mode 0 adds extra delays (albeit only 1/2 clock) before the clock starts toggling; and that deslecting cards except between requests or while the card issues BUSY, falls into the "undefined behavior" category. So while that might not be able to trigger certain perversions, dropping a few clocks in some odd cases would not seem to violate the spec... - Dave ------------------------------------------------------------------------- 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
