Re: [PATCH 2/3] spi: bitbang: add lsb first support

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

On Thu, Mar 13, 2014 at 07:11:36PM +0100, Gerhard Sittig wrote:
> On Wed, Mar 12, 2014 at 21:35 +0000, Mark Brown wrote:

> > I was wondering myself, but on the other hand that's an extra operation
> > and this is about as CPU intensive as one can get.

> Actually I thought that bitbanging pins including the timing
> would be the most expensive part, and that swapping bits might
> not be negligable but could be acceptable in comparison.  But
> this was just a guess, no research was done.

I've not done any research here either really.  My thinking here is
based on the fact that everything other than the delays is essentially
overhead on those delays that stretches the time taken to perform the
overall operation.

> BTW are these bitbang routines referenced from several sites, not
> only spi-gpio.c.  They encode "be" in their name which might
> become misleading then they operate in LSB mode as well.

Indeed.

> And spidelay() appears to sometimes be a NOP -- could this be the
> reason for unreliable data transmission and bit errors in certain
> environments (optimized code, inlined GPIO access, fast CPU, slow
> SPI slave), instead of the suspected receiver's bit shifting?

That's a very interesting observation - I hadn't noticed that this was
the case.  That code is pretty old, modern processors are a lot faster
and it does seem entirely possible that we're able to bash data out
quickly enough to cause problems for some systems, especially if the
timing is uneven which I'd not be surprised by.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]