[PATCH 3/4] spi: bcm2835aux: set up spi-mode before asserting cs-gpio
martin at sperl.org
Wed Feb 10 15:19:39 PST 2016
> On 10.02.2016, at 21:26, Stephan Olbrich <stephanolbrich at gmx.de> wrote:
> Am Wednesday 10 February 2016, 19:02:04 schrieb Mark Brown:
>> On Wed, Feb 10, 2016 at 10:59:29AM -0800, Eric Anholt wrote:
>>> 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
> 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:
at end of 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).
More information about the linux-rpi-kernel