lkml.org 
[lkml]   [2006]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [spi-devel-general] Re: question on spi_bitbang
Date

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/

\
 
 \ /
  Last update: 2006-03-31 22:54    [W:2.106 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site