The patch series does the following
1. Optimises the workqueue to have 1 workqueue per controller so
that one data of one queue doesnt interfere with other.
Earlier discussion thread
Currently all the spi controllers share the work queue.
This patch allocates a work queue per controller.
Signed-off-by: Steve Wilkins steve.wilk...@raymarine.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 19 +++
1 files changed, 11
Currently McSPI driver doesnt follow correct failure fallback steps
attempting to correct the same.
Also
- label names changed to give meaningful names.
- Setting the driver data to NULL in remove
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
Signed-off-by: Shubhrajyoti D
omap mcspi probe() doesnt call pm_runtime disable functions
in case of failure. remove() doesnt call pm_runtime disable. This could
lead to warnings as below on subsequent insmod.
~# insmod spi-omap2-mcspi.ko
[ 255.383671] omap2_mcspi omap2_mcspi.1: Unbalanced pm_runtime_enable!
...
This patch
The patch series does the following
1. Optimises the workqueue to have 1 workqueue per controller so
that one data of one queue doesnt interfere with other.
Earlier discussion thread
On Friday 28 October 2011 05:11 PM, Shubhrajyoti D wrote:
The patch series does the following
1. Optimises the workqueue to have 1 workqueue per controller so
that one data of one queue doesnt interfere with other.
Earlier discussion thread
Hi,
Can I use GPIO pins on my i.mx53 for SPI chip select, I have found little
on the web that can help me, I am hoping that it is straight-forward enough
for me to implement it? Perhaps there is a macro that I can use in the
spi_board_info structure that will let me declare the GPIO?
If it is
