Re: spi-bitbang inverted logic?

[Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>]

On Thu, 15 Mar 2012 12:09:42 +0100 (CET), Guennadi Liakhovetski <g.liakhovetski-Mmb7MZpHnFY@public.gmane.org> wrote:
> Hi all
> 
> I stumbled across this code in spi-bitbang.c:
> 
> 		list_for_each_entry (t, &m->transfers, transfer_list) {
> 			...
> 			cs_change = t->cs_change;
> 			...
> 			if (!cs_change)
> 				continue;
> 			...
> 			/* sometimes a short mid-message deselect of the chip
> 			 * may be needed to terminate a mode or command
> 			 */
> 			ndelay(nsecs);
> 			bitbang->chipselect(spi, BITBANG_CS_INACTIVE);
> 			ndelay(nsecs);
> 		}
> 		...
> 
> 		/* normally deactivate chipselect ... unless no error and
> 		 * cs_change has hinted that the next message will probably
> 		 * be for this chip too.
> 		 */
> 		if (!(status == 0 && cs_change)) {
> 			ndelay(nsecs);
> 			bitbang->chipselect(spi, BITBANG_CS_INACTIVE);
> 			ndelay(nsecs);
> 		}
> 
> So, IIUC, on the first occurrance cs_change is interpreted as "true == 
> have to disable CD," whereas the second one does the opposite. Shouldn't 
> the latter one be inverted?

Actually, I suspect that cs_change is being abused here to allow multiple
messages to operate over a single cs_change assertion.  It does look dodgy,
but I think you'll need to audit the users of cs_change to ensure that every
'normal' message has cs_change asserted for the last transfer in a message.

g.


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure