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

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

On Mar 31, 2006, at 2:36 PM, David Brownell wrote:

> On Friday 31 March 2006 12:00 pm, Kumar Gala wrote:
>
>> 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.
>
> In your case, it sounds like setup() will just store data, and you'll
> want a different method to actually grab that data and use it to stuff
> your controller registers before actually transferring data.  The
> transfer() method just queues transfers (and maybe kicks them off).
>
> Remember that setup() is generally a one-time thing.  Fancier hardware
> will use it to store clock, mode, wordsize, and other parameters into
> a hardware register so that starting a transfer is very quick.  In  
> your
> case, there's no such register, so starting transfers is slower.
>
> One thing to keep in mind is that while I believe the spi_bitbang code
> ought to support controllers like the one you're working with, I don't
> know that anyone has done that yet.  So patches might be necessary.

What I'm looking at is the following:

* use spi_bitbang_setup() as is
* have my chipselect do:
	if (BITBANG_CS_INACTIVE)
		deassert GPIO pin for CS
	else
		set HW mode register (polarity, phase, bit length)
		assert GPIO pin for CS
* setup_transfer()
	* set HW mode register (bit length)
	* call bitbang_setup_transfer()

> At the top of <linux/spi/spi_bitbang.h> are verbal sketches of three
> types of "bitbang" drivers.  Implementations of two of them now seem
> to be working (word-at-a-time with GPIO bitbanging, "spi_butterfly"
> being one of a few examples; and transfer-at-a-time, "omap_uwire").
> Your hardware would be of the third type.
>
>
>
>>>> 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.
>
> The patch allowing the per-transfer overrides, which you were going to
> grab from the MM tree.
>
> That would support SPI drivers for things like bitmapped displays,  
> some
> of which need oddball things like 9-bit commands followed by 8-bit  
> data.

Right, I dont think I need the support of setup_transfer() for my  
devices aren't
changing their settings mid message.  However, I do think some  
changes are needed to the patch

- kumar