David Brownell wrote: > On Friday 29 February 2008, Ned Forrester wrote: >> David Brownell wrote: >>> On Friday 29 February 2008, Ned Forrester wrote: > > The spi_board_info is used only to create a spi_device. > > A SPI master controller is responsible for managing the > spi_device.chip_select when it starts to perform the > spi_message interactions with a given spi_device.
Oops, I forgot to distinguish between spi_board_info (used once) and spi_device (used always). Understood. >> Does some hardware provide a bunch of dedicated chip select pins that >> the controller driver must manipulate as required? > > Yes. And in PXA those chipselects are normally implemented > using GPIO lines. OK, this is the missing link that I never realized before. I could never figure out how a master driver could know what to do with a chip select index, having no other clues. I did not know that some hardware has multiple dedicated CS pins. Understood now. >> If so, is spi_board_info.chip_select just an selection index used only >> by the controller driver to tell it which dedicated pin to use? > > Well, spi_device.chip_select ... but otherwise, yes. Right. Got it, I mixed up spi_board_info and spi_device again. >> If there is hardware that has specific, dedicated pins for chip selects, >> and those pins are always known to be under the sole control of the >> controller driver, then I guess that would explain why >> spi_board_info.chip_select is useful in those cases. > > The chipselect number is always useful when the SPI bus has more > than one slave; it's how the slaves are distinguished. Ahh... Here is a place where pxa2xx-spi departs from the SPI framework by choice. That driver never uses spi_device.chip_select because each chip supplies its own private struct pxa2xx_spi_chip.cs_control at board setup time, passed as struct spi_board_info.controller_data, registered with spi_register_board_info(), and retrieved by pxa2xx_spi.c using spi->controller_data. I gather you can register one of these for each chip attached to the spi bus. Thus the driver gets the cs_control function attached to each spi_device.controller_data. This data can be manipulated by the protocol driver, if needed, to adjust the various private device parameters in that structure, which could include cs_control(). The driver retrieves this information from spi_device (actually from a private structure attached to spi_device.controller_state and initialized in setup()) each time a message is processed. [It makes my head hurt to trace this out :-) ] Because each chip needs its own, unique cs_control() function, and this function pointer is available at message time, there is no need for pxa2xx_spi.c to use the spi_device.chip_select field to distinguish the CS functions. I suppose that it could alternatively been implemented by storing the cs_control pointers in an array during setup(), and then using the index in spi_device.chip_select to access the various functions. Either way seems to work. Thanks for clearing this up. I understand now. -- Ned Forrester [EMAIL PROTECTED] Oceanographic Systems Lab 508-289-2226 Applied Ocean Physics and Engineering Dept. Woods Hole Oceanographic Institution Woods Hole, MA 02543, USA http://www.whoi.edu/sbl/liteSite.do?litesiteid=7212 http://www.whoi.edu/hpb/Site.do?id=1532 http://www.whoi.edu/page.do?pid=10079 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
