Как вызывается вызов probe()? Кто называет это? По моему пониманию, __init() регистрирует driver, а затем как-то probe() вызывается в register данные устройства и irq и т.д. Как именно это происходит?
Я работаю над драйвером сенсорного экрана, а его __init записывается в i2c driver. Затем зонд ожидает i2c_clien t данных, которые возвращают значение null. Я хочу отслеживать, где он заполняется.
Короче говоря: функция probe() драйвера вызвана в результате вызова register_driver для этой конкретной шины. Точнее, он назывался probe() этой структуры bus_type. В вашем случае: i2c_bus_type.
Здесь цепочка вызовов в вашем случае I2C:
Я подготовил график, который отслеживает функцию зонда платформы. Вы работаете с драйвером I2C, который AFAIK является драйвером платформы. Надеюсь, это поможет вам проследить проблему.
Кроме того, посмотрите следующую ссылку, чтобы увидеть обсуждение kernelnewbies.
https://www.mail-archive.com/kernelnewbies%40kernelnewbies.org/msg12423.html
@iSegFault: будет вызван пробник(), чтобы убедиться, что устройство существует, и функциональность прекрасна. Если устройство не является "горячим" подключением, функция probe() может быть помещена внутри init(). Это уменьшит время работы памяти во время работы драйвера. P.S ссылка
Зонд() происходит во время загрузки устройства или при подключении устройства. Для "платформенного" устройства функция зонда вызывается, когда зарегистрировано платформенное устройство, и имя устройства совпадает с именем, указанным в драйвере устройства. P.S ссылка
Функция i2c_detect проверяет адаптер I2C, ища разные адреса, указанные в структуре addr_data. Если устройство найдено, функция chip_detect вызывается. P.S ссылка.
Одна ссылка, которая, несомненно, очистит ваши сомнения. P.S ссылка
В ядре 2.4.29 я могу показать вам, как происходит зондирование? См. Ниже (Имя файла: драйверы /acorn/ char/pcf8583.c)
static struct i2c_driver pcf8583_driver = {
name: "PCF8583",
id: I2C_DRIVERID_PCF8583,
flags: I2C_DF_NOTIFY,
attach_adapter: pcf8583_probe, /* This will be called from i2c-core.c P.S see below function i2c_add_driver()*/
detach_client: pcf8583_detach,
command: pcf8583_command
};
Имя файла: драйверы /i 2c/i2c-core.c
int i2c_add_driver(struct i2c_driver *driver)
{
........................
........................
/* now look for instances of driver on our adapters
*/
if (driver->flags& (I2C_DF_NOTIFY|I2C_DF_DUMMY)) {
for (i=0;i<I2C_ADAP_MAX;i++)
if (adapters[i]!=NULL)
/* Ignore errors */
driver->attach_adapter(adapters[i]); /*This is a location from where probe is called. Pointer **driver** is of type **pcf8583_driver** which you have passed into this function*/
}
ADAP_UNLOCK();
return 0;
}
Несколько важных ссылок:
1) http://www.slideshare.net/varunmahajan06/i2c-subsystem-in-linux2624
2) http://www.programering.com/a/MjNwcTMwATM.html
3) http://www.linuxjournal.com/article/6717
4) http://www.developermemo.com/2943157/
5) http://free-electrons.com/doc/kernel-architecture.pdf
6) http://www.techques.com/question/1-3014627/Probe-problem-when-writing-a-I2C-device-driver
В PCI для ядра 2.4.29 он вызывается при идентификации идентификатора поставщика и устройства. Драйвер шины PCI сделает это за вас. См. Ниже код:
Имя файла: drivers/pci/pci.c
static int pci_announce_device(struct pci_driver *drv, struct pci_dev *dev)
{
const struct pci_device_id *id;
int ret = 0;
if (drv->id_table) {
id = pci_match_device(drv->id_table, dev); /* check for device presence*/
if (!id) {
ret = 0;
goto out;
}
} else
id = NULL;
dev_probe_lock();
if (drv->probe(dev, id) >= 0) { /* This is a location from where probe is called*/
dev->driver = drv;
ret = 1;
}
dev_probe_unlock();
out:
return ret;
}
Рассмотрим пример a platform device driver:
Функция запуска запуска для обратного вызова driver->probe() - это макрос module_init(), вызываемый при загрузке драйвера; этот macro определяется в include/linux/module.h.
module_init(my_driver_init) имеет функцию обратного вызова my_driver_init(). my_driver_init() функция должна иметь вызов platform_driver_register(my_driver)
platform_driver_register(my_driver) присваивает дескриптор my_driver -> probe() универсальному drv -> probe() и вызывает функцию driver_register(my_driver).
driver_register(my_driver) добавляет my_driver к шине платформы и вызывает функцию driver_attach().
Точно так же даже platform_device необходимо подключить к шине платформы.
Наконец, только если driver_match_device() возвращает успех на основе .name и .id_table совпадений driver в списке устройств платформы, который приходит либо из ACPI/DTS, затем driver_probe_device() получает вызов, который имеет обратный вызов drv->probe().
Функция зонда будет вызываться для каждого интерфейса обнаруженного устройства, кроме тех, которые уже зарегистрированы.
Функция зонда будет вызвана, когда имя будет соответствовать структуре драйверов формы для структуры устройства. Ниже упоминается, например, как для структуры драйвера, так и для устройства.
1: Структура драйвера
static struct driver your_driver = {
.driver = {
.name = YUR_NAME,
},
например.
static struct i2c_driver l3gd20_driver = {
.driver = {
.name = l3gd20_gyr,
}
2: Структура устройства
static structure device your_devices = {
.name = YUR_NAME,
},
например.
static struct i2c_board_info mxc_i2c2_board_info[] __initdata = {
{
I2C_BOARD_INFO("l3gd20_gyr", 0x6a),
},
Примечание. Когда имя (l3gd20_gyr) из драйвера и устройства будет соответствовать вашему зонду, он получит вызов.