Re: [patch 2.6.22-git5 0/4] MMC-over-SPI

[Anton Vorontsov <avorontsov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>]

On Thu, Jul 19, 2007 at 01:28:17PM -0700, David Brownell wrote:
> On Thursday 19 July 2007, Anton Vorontsov wrote:
> > > 
> > > Thanks.  In that case, I'm thinking there *IS* a bug of some kind
> > > in the controller driver Anton is using, else mode 3 would work
> > > for him like it (evidently) works for everyone else.
> > 
> > I've checked with MPC8323E reference manual, and according to it
> > spi_mpc83xx is doing right thing.
> 
> I notice that driver disregards the cs_change instructions in the
> messages ... I could imagine how that could make a big difference.
> 
> 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.

> > > I'll see about making time to see if mode 0 works for me too; but
> > > even if it does, I'd prefer to leave the driver the way it is now
> > > instead of changing it to cover up for that mpc83xx bug ... plus,
> > > I just like CPHA=1 modes better because they don't need to start
> > > with that strange half-clock.  ;)
> > 
> > Well. As Pierre Ossman told, it should work at any mode.
> 
> Well, either mode 0 or mode 3.  And since it doesn't work in both
> modes, clearly something in your test system is buggy.
> 
> 
> > That also 
> > proves that it's not mpc83xx's bug (because even if it would be a
> > bug, and spi_mpc83xx having inversed values, it's still should work).
> 
> No way could it "prove" that!!
> 
> How could it ever be possible that your system not work in mode 3, and
> yet that not be a bug in your test system???
> 
> The only thing "proven" is that the mmc_spi code is basically correct;
> otherwise neither clock mode could cause the right data transfers.
> (And otherewise other folk wouldn't have seen it work...)
> 
> The problem is in a lower level ... maybe the SPI controller driver,
> or the silicon, or the board wiring.
> 
> 
> > So, it's likely depends on spi controller, maybe some timing issues
> > or signal shapes, which distracts SD/MMC... Not sure.
> 
> What does your oscilloscope show is going on when this error triggers?

Well, it's not handy to catch particular bit using my oscilloscope.
It's unable to scroll in time. But as failing bits are in the last
spi message, maybe I could do something.

> Right now I'd most suspect the lack of cs_change support in that
> controller driver.

I see. Thanks for the pointer.

> > But then, may I ask for "alt_mode" (bool) platform data variable?
> 
> Well, as already said:  (a) we know mode 3 is required to work,
> (b) we know that on your test system it doesn't, so accordingly
> (c) we know there's a bug in your test system.
> 
> The only reason to add such a flag would be to paper over that bug.
> 
> The idea with bugs is to *FIX* them, not paper them over so they'll
> never get fixed.  Especially if you've got a lab setup with even
> basic hardware debug tools, like your oscilloscope, which make it
> so easy to verify that the right signals are going down the wires.

Yeah, you're right. And your whole reply makes a lot of sense, much
thanks for explanations and ideas.

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

-------------------------------------------------------------------------
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