Hi David,
On Tue, May 19, 2009 at 09:34:14PM -0700, David Brownell wrote:
> Normal behavior of a spi_message is to keep the chipselect active
> during the entire message, then deactivate it after the last transfer.
> Setting the cs_change flag *changes* that behavior ... allowing either
> (a) brief mid-message deselection, usually to make a message hold a
> composite transaction, or else (b) hinting that immediate deselection
> isn't neccessary, as a possible performance tweak for some drivers.
>
> Note that while (a) is mandatory -- drivers that can't do it must
> reject the messages using it -- (b) is optional. When the next
> message goes to a different device, obviously the chip selection
> lines will need to change.
Thanks for the clarification.
If I understood correctly then, cs_change has two opposite meanings:
1. If cs_change != 0 in spi_transfer that is not the last in the current
spi_message, then deactivate the chip select between this spi_transfer and
the next.
2. If cs_change != 0 in spi_transfer that is that last in the current
spi_message, then the SPI controller is allowed to NOT deactivate the chip
select after the current spi_message.
Is this correct? If so would a clarification of the relevant text at
include/linux/spi/spi.h be accepted?
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
spi-devel-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
