[U-Boot-Users] [PATCH v2] spi: Kill spi_chipsel table and introduce spi_setup()

[Ben Warren]

Mike Frysinger wrote:
> On Wednesday 06 February 2008, Ben Warren wrote:
>   
>> Haavard Skinnemoen wrote:
>>     
>>> On Tue, 5 Feb 2008 23:34:46 -0500
>>> Mike Frysinger <vapier at gentoo.org> wrote:
>>>       
>>>> there isnt a function to pair up with spi_setup() ?  for example, the
>>>> normal communication flow with a SPI flash:
>>>>  - spi_setup - turn on SPI
>>>>  - spi_cs_activate - assert CS
>>>>  - spi_xfer -
>>>> 	- op code (read/write/erase)
>>>> 	- address
>>>> 	- actual block data
>>>>  - spi_cs_deactivate - deassert CS
>>>>  - ??? - turn off SPI
>>>>         
>>> Right. I thought of spi_setup() more as a function that needs to be
>>> called one time per slave to set up communications parameters, not
>>> really for turning the SPI on as such.
>>>
>>> But perhaps it would make sense to combine those two functions. How
>>> about we turn it into
>>>
>>> /* Set slave-specific parameters and enable SPI */
>>> int spi_claim_bus(int cs, unsigned int max_hz, unsigned int mode);
>>>
>>> /* Disable SPI */
>>> void spi_release_bus(int cs);
>>>
>>> The claim/release naming also makes it clear that the SPI device driver
>>> has exclusive access to the bus between those two calls.
>>>       
>> If there really is a need to turn off the controller, or change the
>> transfer rate on the fly, then this is good. OTOH, this is a bootloader,
>> not an OS, and probably the vast majority of use cases would just be to
>> initialize the controller to a speed that all devices can handle,
>> transfer some data to/from one or more devices, then boot an OS. Maybe
>> some people need to do more, I don't know.
>>     
>
> U-Boot's design principles dictates that you get in, do your thing, and get 
> out.  getting out means breaking down/releasing/turning off/however you want 
> to describe it.  there is also the possibility of slight power savings as 
> Haavard points out.  you could also have board functions that reuse the pins 
> for some other purpose (say they have muxing in place or something).
>
>   
True.  I just want to be careful we don't over-engineer this...
>>>> also, what's the deal with spi_xfer() taking a length in # of bits ?  is
>>>> it realistic to transmit anything less tan 8 bits ?  the Linux kernel
>>>> driver does not support this, so it cant be a big need ...
>>>>         
>>> I don't know. That's unchanged from the original API. But I certainly
>>> wouldn't object if we turned it into a length in bytes.
>>>       
>> I seem to remember working with a Broadcom device where some of the
>> transfers were odd numbers of nibbles (e.g. 12 bits). Not necessarily a
>> reason to keep bit granularity, but I don't see a reason to artificially
>> limit things either.
>>     
>
> but is there any real spi controllers that can transmit less than a byte at a 
> time ?  i guess if you consider gpio-based soft spi ...
> -mike
>   
Sure, the Freescale SPI controller that I wrote a driver for (MPC8xxx) 
can send an arbitrary number of bits.  Not sure exactly where that's 
useful, but my worldview is limited to high-powered telecom/datacom 
equipment.

regards,
Ben