[PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting cs-gpio

On 10.02.2016, at 21:26, Stephan Olbrich [off-list ref] wrote:

Am Wednesday 10 February 2016, 19:02:04 schrieb Mark Brown:

quoted

On Wed, Feb 10, 2016 at 10:59:29AM -0800, Eric Anholt wrote:

quoted

Oops, this makes more sense now.  Subject even mentioned gpio, and a
GPIO CS must be getting set around the transfer_one call.  I'll be ready
to send an r-b for a v2 with the speed update bug fixed (unless transfer
speeds are guaranteed to be constant between a prepare and unprepare).

No guarantee that they'll not change, especially in a situation where we
have two devices on different speeds on a bus working at the same time.

Are you saying, that between a prepare and unprepare there could be transfers 
for another device? Then all the clock setting couldn't be done in prepare 
either.
Apart from that, if two transfers in the same message are not guarantied to 
have the same speed, this still needs to be fixed. I'll roll a v2.

Prepare/unprepare is always called when processing an spi message.
there is never a phase where two spi_messages are prepared concurrently
for the same spi bus.

See the implementation of __spi_pump_messages

The sequence for processing is:
* master->prepare_hardware
* master->prepare_message
* spi_map_message
* master->transfer_one_message
  * spi_set_cs(true)
  at end of message:
  * spi_finalize_current_message
    * spi_set_cs(false)
    * master->unprepare_message 

So the use of prepare_message in this context is valid.

Otherwise we would need to add an additional method to setup
polarity/cs prior to spi_set_cs(true).

Ciao,
	Martin