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

[Mike Frysinger]

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).

> >> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080206/7afe2d06/attachment.pgp