[U-Boot-Users] [PATCH v2 1/3] New i.MX31 SPI driver

[Guennadi Liakhovetski]

On Thu, 8 May 2008, Haavard Skinnemoen wrote:

> But I have to say I like the idea about passing a spi_slave
> "handle" around...
> 
> How about something like this?
> 
> /*
>  * Set up communication parameters for a SPI slave. This doesn't
>  * necessarily enable the controller.
>  */
> struct spi_slave *spi_create_slave(int bus, int cs, unsigned int
> 		max_hz, unsigned int mode);

Don't quite like the "create" name. To me it sounds like "we just create a 
slave object for you, do what you want with it." Whereas, I was thinking 
about an "attach" method, where the host driver adds the slave pointer to 
its driver list, possibly initializes the hardware, and can always verify 
whether the slave pointer it is handed in by one of further method is 
indeed one of the drivers on the list.

> /*
>  * Get exclusive access to the SPI bus for communicating with the given
>  * slave. Returns a negative value if the bus is busy (drivers may omit
>  * such checks if they don't want the extra code/data overhead.)
>  */
> int spi_claim_bus(struct spi_slave *slave);

Is this needed? Getting the spi_slave handle you gain exclusive access to 
the spi device, but claiming the whole bus? Drivers may be lazy releasing 
the chip-select between transfers, but are there cases where you _really_ 
must have exclusive access to the bus or cannot release the cs?

> /*
>  * Release the SPI bus. This may disable the controller and/or put it
>  * in low-power mode
>  */
> void spi_release_bus(struct spi_slave *slave);
> 
> /*
>  * Transfer data on the SPI bus.
>  *
>  * flags can be a combination of any of the following bits:
>  *   SPI_XFER_BEGIN: Assert CS before starting the transfer
>  *   SPI_XFER_END: Deassert CS after the transfer
>  */
> int spi_xfer(struct spi_slave *slave, int bitlen, const void *dout,
> 		void *din, unsigned long flags);

See above - would anything break if we just deassert the cs between 
transfers?

> What do you think?

Yes, looks good, just let's iron out my remarks above, and see if anyone 
else has any comments.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de