Messages in this thread | | | From | Kumar Gala <> | Subject | Re: [spi-devel-general] Re: question on spi_bitbang | Date | Fri, 31 Mar 2006 14:52:02 -0600 |
| |
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/
| |