>-----Original Message----- >From: David Brownell [mailto:[EMAIL PROTECTED] >Sent: Tuesday, October 16, 2007 11:29 PM >To: [email protected]; [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: [spi-devel-general] Status of Linux SPI slave
> >> Now we are changing the role what the SPI controller and the device is >> playing. SPI controller will now work as slave and device will be master >to >> the slave SPI controller. >I don't follow that comment. What do you mean when you say "device"? Ok, I am adhering to the convention specified in Documentation/spi/spi-summary. We know that SPI controller driver is a master controller driver and spi protocol driver is for slave device. (e.g., TouchScreen will have a spi protocol driver and registers to stack with spi_driver_register() ). When I say "device" I meant SPI device (which is slave device for SPI master controller driver). Now, if the exisiting SPI controller driver (Which is a master controller as of now) is modified to work in slave, then we would be having a Slave SPI controller driver and spi device would be a master. I hope this time I'm making myself clear :D. > >I'm guessing I will disagree with your comment about being master to >the slave. There's only one master in the system, and it's not on the >slave side. The slave driver must *REACT* to the master, which is why >I said the interaction model must be different. Yes, agreed about interaction model part. Ok, to be clearer. I will be having a SPI slave controller registering to stack (Assuming Stack gives me spi_slave framework). Now, how does the protocol driver should fit in? It would still be for spi device(which will be a master). Right? This is what I meant. >> I had to only take care of module control registers and to deactivate >the >> cs0 between spi words as required by slave. And also correct >configuration >> of mosi/simo lines for slave. > >I'm still not following what you're saying here. By definition, a >slave has no control of chipselect ... the master manages that signal. > Actually, I have used the default master controller driver and modified it to work as slave controller driver. So, I had to remove the asserting of spi_cs between words which guess only works for master mode. This is what I meant. >Configuration of MOSI and MISO lines sounds like what you've actually >got is DI and DO lines, which would need to be manually interchanged >if the M and S roles change. If the signal lines are true MOSI and >MISO, the signal direction would change by the internal M/S switch. > Yes. > >Any badly written software can have redudant code. :) > I was just contemplating how much code can be reused for slave support in stack :) > >Slave support in a SOC is, I've assumed, mostly used with >custom chip-to-chip communications. > Ok. And ya, It would be better if I list down some points from top of my head, it will make me clear. Following things done for slave; 1. Make SPI controller work in Master and Slave. There won't be any separate controller driver for slave. (As of now there is no support from stack, so stack will be blind about slave transaction) 2. Protocol driver will still register as spi_driver. No change here, only difference is that the underlying device would be a master device and in spi_board_info table it will populate a SPI controller info which will be working as slave. 3. One more thing I wanted to ask was about spi_setup(). How about supporting selecting/deselecting SPI mode (master/slave) through spi_setup()? We can make protocol driver free enough to override selection of SPI mode(master/slave). 4. If only single controller driver is used for Master/Slave, then by default it should be registering as Master/slave with stack? Actually, I have couple of slave model floating in my mind with lots of questions :). I think I'll go back and try to understand more about transaction model required in slave, so that I can consolidate things upon that. Regards, Girish ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
