summaryrefslogtreecommitdiff
path: root/samples
diff options
context:
space:
mode:
authorVirupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>2011-11-10 07:13:24 (GMT)
committerLinus Walleij <linus.walleij@linaro.org>2011-12-01 16:16:08 (GMT)
commit8b8d719161c386668161daf29b2632f094e326c8 (patch)
treef7c182a6b6e2cf08455af11915b37b92f6c766c7 /samples
parent53e4acea0e819a6a8513e10a0773f2259ede0481 (diff)
downloadlinux-8b8d719161c386668161daf29b2632f094e326c8.tar.xz
spi/pl022: make the chip deselect handling thread safe
There is a possibility that the pump_message and giveback run in parallel on a SMP system. Both the pump_message and giveback threads work on the same SPI message queue. Results will be in correct if the pump_message gets to work on the queue first. when the pump_message works with the queue, it reads the head of the queue and removes it from the queue. pump_message activates the chip select depending on this message read. This leads to giveback working on the modified queue or a emptied queue. If the queue is empty or if the next message on the queue (which is not the actual next message, as the pump message has removed the next message from the queue) is not for the same SPI device as that Of the previous one, giveback will de-activate the chip select activated by pump_message(), which is wrong. To solve this problem pump_message is made not to run and access the queue until the giveback is done handling the queue. I.e. by making the cur_msg NULL after the giveback has read the queue. Also a state variable has been introduced to keep track of when the CS for next message is already activated and avoid to double-activate it. Reviewed-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'samples')
0 files changed, 0 insertions, 0 deletions