Protocol driver probe function never invoked

[llandre]

Hi all,

I'm working with kernel 2.6.21.3 on Freescale iMXL-based platform.
I have to write a SPI protocol driver for Quantum QT510 touch controller.
As starting point for board-init code I used the driver released by
Pavel Pisa:
http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/pimx1-board-spi.patch

In protocol driver I defined spi_driver like this:

static struct spi_driver qt510_driver = {
.driver = {
.name = QT510_MODALIAS,
.owner = THIS_MODULE,
},
.probe = qt510_probe,
.remove = __devexit_p(qt510_remove),
};

static int __init qt510_init(void)
{
return spi_register_driver(&qt510_driver);
}
module_init(qt510_init);


In board-init code I used the same name for modalias field:


static struct spi_board_info parsy_spi_board_infos[] __initdata = {
{
.modalias = "loopback",
.max_speed_hz = 1600000,
.bus_num = 1,
.chip_select = 0x00,
.mode = SPI_MODE_0,
.controller_data = &spi_controller_data[0],
},
{
.modalias = QT510_MODALIAS,
.max_speed_hz = QT510_SPI_CLK_MAX,
.bus_num = 1,
.chip_select = 0x01,
.mode = SPI_MODE_3,
.controller_data = &spi_controller_data[1],
},
{
.modalias = "tbd",
.max_speed_hz = 1600000,
.bus_num = 1,
.chip_select = 0x2,
.mode = SPI_MODE_0,
.controller_data = &spi_controller_data[2],
},
};


However the probe function (qt510_probe) is never invoked.
In my understanding this is due to the fact that there are no devices
associated to the bus:

bash-3.00# ls -la /sys/bus/spi/devices/
total 0
drwxr-xr-x 2 root root 0 Jan 1 1970 .
drwxr-xr-x 4 root root 0 Jan 1 1970 ..
bash-3.00# ls -la /sys/bus/spi/drivers/
total 0
drwxr-xr-x 4 root root 0 Jan 1 1970 .
drwxr-xr-x 4 root root 0 Jan 1 1970 ..
drwxr-xr-x 2 root root 0 Jan 1 1970 qt510
drwxr-xr-x 2 root root 0 Jan 1 1970 spidev
bash-3.00#

Am I missing something?

TIA,
llandre

DAVE Electronics System House - R&D Department
web: http://www.dave-tech.it
email: r&d2-4VKA1VU3ct/j+***@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[llandre]

The probe function is not invoked because the controller does not allow
to reach the max_speed_hz.
I did not realize this before because, even if the debug messages were
enabled, I did not see any warning message about this.
--
llandre

DAVE Electronics System House - R&D Department
web: http://www.dave-tech.it

Post by llandre
Hi all,
I'm working with kernel 2.6.21.3 on Freescale iMXL-based platform.
I have to write a SPI protocol driver for Quantum QT510 touch controller.
As starting point for board-init code I used the driver released by
http://rtime.felk.cvut.cz/repos/ppisa-linux-devel/kernel-patches/current/pimx1-board-spi.patch
static struct spi_driver qt510_driver = {
.driver = {
.name = QT510_MODALIAS,
.owner = THIS_MODULE,
},
.probe = qt510_probe,
.remove = __devexit_p(qt510_remove),
};
static int __init qt510_init(void)
{
return spi_register_driver(&qt510_driver);
}
module_init(qt510_init);
static struct spi_board_info parsy_spi_board_infos[] __initdata = {
{
.modalias = "loopback",
.max_speed_hz = 1600000,
.bus_num = 1,
.chip_select = 0x00,
.mode = SPI_MODE_0,
.controller_data = &spi_controller_data[0],
},
{
.modalias = QT510_MODALIAS,
.max_speed_hz = QT510_SPI_CLK_MAX,
.bus_num = 1,
.chip_select = 0x01,
.mode = SPI_MODE_3,
.controller_data = &spi_controller_data[1],
},
{
.modalias = "tbd",
.max_speed_hz = 1600000,
.bus_num = 1,
.chip_select = 0x2,
.mode = SPI_MODE_0,
.controller_data = &spi_controller_data[2],
},
};
However the probe function (qt510_probe) is never invoked.
In my understanding this is due to the fact that there are no devices
bash-3.00# ls -la /sys/bus/spi/devices/
total 0
drwxr-xr-x 2 root root 0 Jan 1 1970 .
drwxr-xr-x 4 root root 0 Jan 1 1970 ..
bash-3.00# ls -la /sys/bus/spi/drivers/
total 0
drwxr-xr-x 4 root root 0 Jan 1 1970 .
drwxr-xr-x 4 root root 0 Jan 1 1970 ..
drwxr-xr-x 2 root root 0 Jan 1 1970 qt510
drwxr-xr-x 2 root root 0 Jan 1 1970 spidev
bash-3.00#
Am I missing something?
TIA,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave-tech.it
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
spi-devel-general mailing list
https://lists.sourceforge.net/lists/listinfo/spi-devel-general

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[David Brownell]

Post by llandre
The probe function is not invoked because the controller does not allow
to reach the max_speed_hz.
I did not realize this before because, even if the debug messages were
enabled, I did not see any warning message about this.

I want to be sure I understand this correctly. You're saying that
the call to spi_setup() inside of spi_new_device() failed silently?
And thus the scan_boardinfo() failed?

If so, I'm thinking the following patch would help ... right?

--- g26.orig/drivers/spi/spi.c 2007-07-24 06:27:04.000000000 -0700
+++ g26/drivers/spi/spi.c 2007-07-24 06:26:39.000000000 -0700
@@ -325,9 +325,17 @@ static void scan_boardinfo(struct spi_ma
unsigned n;

for (n = bi->n_board_info; n > 0; n--, chip++) {
+ int status;
+
if (chip->bus_num != master->bus_num)
continue;
- (void) spi_new_device(master, chip);
+ status = spi_new_device(master, chip);
+ if (status < 0)
+ dev_err(master->cdev.dev,
+ "can't create spi_device, err %d; "
+ "chipselect %d, modalias %s\n",
+ status, chip->chip_select,
+ chip->modalias);
}
}
mutex_unlock(&board_lock);




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[David Brownell]

I want to be sure I understand this correctly.  You're saying that
the call to spi_setup() inside of spi_new_device() failed silently?
And thus the scan_boardinfo() failed?
If so, I'm thinking the following patch would help ... right?

Helps to run GCC *first* ...

--- g26.orig/drivers/spi/spi.c 2007-07-24 06:31:44.000000000 -0700
+++ g26/drivers/spi/spi.c 2007-07-24 06:31:40.000000000 -0700
@@ -327,7 +327,12 @@ static void scan_boardinfo(struct spi_ma
for (n = bi->n_board_info; n > 0; n--, chip++) {
if (chip->bus_num != master->bus_num)
continue;
- (void) spi_new_device(master, chip);
+ if (spi_new_device(master, chip) == NULL)
+ dev_err(master->cdev.dev,
+ "can't create spi_device for "
+ "chipselect %d, modalias %s\n",
+ chip->chip_select,
+ chip->modalias);
}
}
mutex_unlock(&board_lock);


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[llandre]

Post by David Brownell
I want to be sure I understand this correctly. You're saying that
the call to spi_setup() inside of spi_new_device() failed silently?

No, I did not make myself clear.
I was talking about this code in spi_imx.c:

/* SPI datarate */
tmp = spi_data_rate(spi->max_speed_hz);
if (tmp == SPI_CONTROL_DATARATE_BAD) {
status = -EINVAL;
dev_err(&spi->dev,
"setup - "
"HW min speed (%d Hz) exceeds required "
"max speed (%d Hz)\n",
spi_speed_hz(SPI_CONTROL_DATARATE_MIN),
spi->max_speed_hz);
if (first_setup)
goto err_first_setup;
else
/* Undo setup using chip as backup copy */


Since the reference clock feeding the SPI controller was too high, it
was not able to generate the required SPI clock. Probably I did not pay
enough attention, but it seems kernel did not print these error messages
so it took a while to recognize that the this was the problem.
--
llandre

DAVE Electronics System House - R&D Department
web: http://www.dave-tech.it
email: r&d2-4VKA1VU3ct/j+***@public.gmane.org

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/