In-Reply-To: <200603311236.02665.david-b@pacbell.net>
References: <1B2FA58D-1F7F-469E-956D-564947BDA59A@kernel.crashing.org> <200603311132.06819.david-b@pacbell.net> <3E572FEF-093B-4359-9FC4-45D00B33C993@kernel.crashing.org> <200603311236.02665.david-b@pacbell.net>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A164CF6D-0330-46A7-ABF2-87127753E048@kernel.crashing.org>
Cc: spi-devel-general@lists.sourceforge.net,
       linux kernel mailing list <linux-kernel@vger.kernel.org>
Content-Transfer-Encoding: 7bit
From: Kumar Gala <galak@kernel.crashing.org>
Subject: Re: [spi-devel-general] Re: question on spi_bitbang
Date: Fri, 31 Mar 2006 14:52:02 -0600
To: David Brownell <david-b@pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2840
Lines: 75


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
-
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/