In-Reply-To: <200603311011.00981.david-b@pacbell.net>
References: <1B2FA58D-1F7F-469E-956D-564947BDA59A@kernel.crashing.org> <200603311011.00981.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: <29F33C89-519A-412B-9615-1944ED29FD9C@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: question on spi_bitbang
Date: Fri, 31 Mar 2006 13:07:45 -0600
To: David Brownell <david-b@pacbell.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2387
Lines: 55


On Mar 31, 2006, at 12:11 PM, David Brownell wrote:

> On Friday 31 March 2006 9:31 am, Kumar Gala wrote:
>> I'm looking at using spi_bitbang for a SPI driver and was trying to
>> understand were the right point is to handle MODE switches.
>>
>> There are 4 function pointers provided for each mode.
>
> That's if you are indeed "bit banging", or your controller is the
> type that's basically a wrapper around a shift register:  each
> txrx_word() function transfers (or bitbangs) a 1-32 bit word in
> the relevant SPI mode (0-3).
>
> There's also a higher level txrx_bufs() routine for buffer-at-a-time
> access, better suited to DMA, FIFOs, and half-duplex hardware.

My controller is just a shift register that I can set the  
characteristics of (bit length for example, reverse data).

>> My controller
>> HW has a mode register which allows setting clock polarity and clock
>> phase.  I assume what I want is in my chipselect() function is to set
>> my mode register and have the four function pointers set to the same
>> function.
>
> I don't know how your particular hardware works, but if you have a
> real SPI controller it would probably be more natural to have your
> setup() function handle that mode register earlier, out of the main
> transfer loop ... unless that mode register is shared among all
> chipselects, in which case you'd use the setup_transfer() call for
> that, inside the transfer loop.  (That call hasn't yet been merged
> into the mainline kernel yet; it's in the MM tree.)

The mode register is shared between chipselects so I'll go pull the  
patches from -mm for setup_transfer().  That sounds like the right  
place for setting my mode register.

> 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()?

It sounds like with the new patch, I'll end up setting txrx_word[] to  
the same function for all modes.

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