On Thu, 15 Mar 2012 12:09:42 +0100 (CET), Guennadi Liakhovetski <[email protected]> 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 _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
