Excerpts from Ben Gamari's message of Wed Jan 20 14:47:23 -0500 2010: > Bcc: > Subject: GPIO chip select support in omap2_mcspi driver > > It seems like the rough idea is to add a cs_gpio field to the device > struct (omap2_mcspi) and add the appropriate code to the > omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The > potential problem I can see with this is that omap2_mcspi_set_enable() > is called to enable the channel before the force_cs() is called (in > omap2_mcspi_work()). If I'm interpreting the documentation correctly, > the enable bit starts the clocks, meaning that the chip will begin > clocking out data before CS is brought high. I must be missing something > here, no?
Could someone comment on how this ordering works? As I said, it seems to me like the SPI controller starts sending before CS is brought high. I would appreciate any feedback. Thanks! - Ben ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
