> Yes, this is a better approach. However, I'd rather see the gpio data > passed as an array to the spi master platform_device via the > private_data structure.
Sorry for my ignorance but I really have no idea how one would hook this up in the board code (which IMHO is where this sort of chip select configuration belongs). Looking at the beagleboard board file I see no reference to a spi master platform_device. The SPI devices are registered through spi_register_board_info. Could you clarify how this would work? > controller_data is really intended to be a pointer that the spi_master > can populate if it needs to, so it is not a good idea to populate it > in setup code instead. That makes sense given the name. > Also, I see cs line wireups more as a property of the controller than > a property of the device (there is some debate on this area, but in > the end it probably is more important to be consistent about how the > data is passed than the relative merits between master-centric or > slave-centric; which really means I get to make the decision about > which approach spi_masters should take). > Fair enough. I could convince myself that either approach makes more sense. - Ben ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
