On Wed, Feb 9, 2011 at 7:25 PM, Aaron Wu <[email protected]> wrote: > Hi Grant, > > Just come back from the long holiday. Thanks very much for the comment and > hints. Following your idea here is some update of our plan: > > Yes the slave can not predict when the transaction is going to happen, and > it takes time before the slave is ready for the transaction after the system > power on, so maybe as a slave we should assert an GPIO to inform the master > that we are ready once we finished the initialization? Then from the > application level, we issue a blockable read, waitting for the master > to initiate the transaction. > > It's also true that what we do next is highly up to what we get from the > master, so we plan to put this protocal related strategy to the userspace. > The application is in charge of analyzing each unit of data the slave > receives, and take the proper action by calling the slave driver operations. > > So basically the slave driver will reside in a sub-directory as you > suggested, export the read/write and a couple of IOCTLs, it is capable of: > -- assert an GPIO once it's ready > -- being configured to operate at different speed, spi_mode 0~3, word > length, etc. > -- read from the master > -- write to the master > -- duplex data transaction with the master > > It will make use of some of the existing data structures for spi master, > without cooperating with them. In the board file, there will be a > slave_spi_board_info, the slave framework will alloc and create related spi > slave device by scanning this table, much the same like how we did for spi > master.
I'm really not a fan of the struct spi_board_info approach. If I were redesigning the spi infrastructure then I would not use this model. You'd be better off registering each spi slave instance separately as platform devices with extra information passed in the platform_data pointer. > > Apart for the common slave driver mentioned above, there will be one spi > slave controller driver file for each of the specific slave controller, > where the slave operations is implemented for different actual slave > controller according to their ASIC IP module specification. > > The main reason that we plan to through the strategy to user space > application is because there is no existing standard for the transacted data > interpretation, this application decide the transaction protocol on behalf > of the slave device, representing the master side programmer a > specification defining the charactor of the slave device. > > Need your feed back before moving forward. I probably won't have much feedback until I actually see an implementation. As long as the spi_slave functionality is distinctly separate from spi master then I don't have any conceptual problems with it. It's the shoehorning spi slave mode into the spi master framework that really bothered me. g. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
