Hi Alan, On Sunday 03 October 2010 17:48:06 Alan Carvalho de Assis wrote: > Hi Sergii, > > On 10/1/10, Sergii Kovalchuk <sentinelofsetch@xxxxxxxxx> wrote: > > Hi all, > > > > Probably, I should ask my quesiton on some SPI dedicated mailing lists, > > however, the borders of "newbiness" are hard to estimate. > > > > As I can see, most SPI controller drivers currently attempting to control > > CS (SS) line by themselves, usually enabling it just before spi_message > > processing and disabling after it. Therefore, all transfers within a > > message are going as one atomic transaction. > > > > However, what should I do, if device requires CS to be triggered to > > active state and remained active until device will trigger IRQ, > > indicating that it awoke and ready for transaction? > > > > I presume, that I need some kind of manual CS control. How does it fit > > into general SPI subsystem paradigm and how I can implement it? > > Some processors let you to control its CS line manually. > > Take a look on this: > arch/arm/plat-mxc/include/mach/spi.h > arch/arm/mach-mx3/mach-mx31lilly.c > > Also you can define a delay time before and/or after the chip select > activation, even on processors with automatic chip select. > > Best Regards, > > Alan It is possible to control CS manually, but this control would be messed by SPI controller. For example, if I will assert CS manually and then start transfer, SPI controller will deassert it at the end of transfer anyway. Right, delay is the only solution in this paradigm, however, it's uneffective and potentially unstable. Probably it would be better to have a kind of completion in the spi_transfer structure. In that way SPI controller code can wait for an event from device using wait_for_completion_timeout() -- Best Regards, Sergii -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
