Messages in this thread | | | From | Kumar Gala <> | Subject | Re: question on spi_bitbang | Date | Fri, 31 Mar 2006 13:17:07 -0600 |
| |
On Mar 31, 2006, at 1:07 PM, Kumar Gala wrote:
> > On Mar 31, 2006, at 12:11 PM, David Brownell wrote: > >> On Friday 31 March 2006 9:31 am, Kumar Gala wrote: >>> I'm looking at using spi_bitbang for a SPI driver and was trying to >>> understand were the right point is to handle MODE switches. >>> >>> There are 4 function pointers provided for each mode. >> >> That's if you are indeed "bit banging", or your controller is the >> type that's basically a wrapper around a shift register: each >> txrx_word() function transfers (or bitbangs) a 1-32 bit word in >> the relevant SPI mode (0-3). >> >> There's also a higher level txrx_bufs() routine for buffer-at-a-time >> access, better suited to DMA, FIFOs, and half-duplex hardware. > > My controller is just a shift register that I can set the > characteristics of (bit length for example, reverse data). > >>> My controller >>> HW has a mode register which allows setting clock polarity and clock >>> phase. I assume what I want is in my chipselect() function is to >>> set >>> my mode register and have the four function pointers set to the same >>> function. >> >> I don't know how your particular hardware works, but if you have a >> real SPI controller it would probably be more natural to have your >> setup() function handle that mode register earlier, out of the main >> transfer loop ... unless that mode register is shared among all >> chipselects, in which case you'd use the setup_transfer() call for >> that, inside the transfer loop. (That call hasn't yet been merged >> into the mainline kernel yet; it's in the MM tree.) > > The mode register is shared between chipselects so I'll go pull the > patches from -mm for setup_transfer(). That sounds like the right > place for setting my mode register.
Now that I look at setup_transfer() more I dont think its what I want. It's only going to get called if the transfer is different from the spi_device() settings. I would seem I would want to configure all of my settings in chipselect().
>> The chipselect() call should only affect the chipselect signal and, >> when you're activating a chip, its initial clock polarity. Though >> if you're not using the latest from the MM tree, that's also your >> hook for ensuring that the SPI mode is set up right. > > Why deal with just clock polarity and not clock phase as well in > chipselect()? > > It sounds like with the new patch, I'll end up setting txrx_word[] > to the same function for all modes. > > - kumar > - > To unsubscribe from this list: send the line "unsubscribe linux- > kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |