Re: [spi-devel-general] Re: question on spi_bitbang

[Kumar Gala <galak@kernel.crashing.org>]

On Mar 31, 2006, at 1:32 PM, David Brownell wrote:

> On Friday 31 March 2006 11:07 am, Kumar Gala wrote:
>> My controller is just a shift register that I can set the
>> characteristics of (bit length for example, reverse data).
>
> I've got a patch somewhere to enable LSB-first transfers in the API,
> though without an implementation, if you're interested.  I'll post it
> as an RFC at some point.

The controllers capable so if/when we have something at a higher  
level I can look at adding support for it.

>>> 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()?
>
> You could, but the point is that you _must_ set the initial polarity
> before setting the chipselect.  Most SPI devices support modes 0  
> and 3,
> and make the choice based on the clock polarity when chipselect goes
> active.  Changing polarity later would start a transfer.  :)

Makes sense about needing to set polarity in the chipselect() before  
the actual chip select.  I just now completely confused on when I  
need to things.

My confusion is about the order of which various things occur.  setup 
(), chipselect() and transfer() vs what's happening in bitbang_work 
().  I don't see how we handle the fact that two different devices  
may require setup() to be called when we switch between them.

>> It sounds like with the new patch, I'll end up setting txrx_word[] to
>> the same function for all modes.
>
> Yes, it does sound like that.  If that works for you, I'd like to see
> that go into 2.6.17 kernels.

I'm not sure I understand what you'd like to see go into 2.6.17.

- kumar