[vpd 0]

Вот примерно такая задачка нарисовалась. Имеется ПЛИС, подключенная к процессору через интерфейс VLYNQ. И хотя исходно VLYNQ предназначен для peer-to-peer соединения, наличие ПЛИС позволяет реализовать несколько подсистем. Ну, для простоты пусть это будут UART 16550, несколько штук. Вопрос заключается в том, можно ли подцепить стандартные драйверы системы и не писать ничего заново?

 

Сам по себе интерфейс VLYNQ, если отбросить его инициализацию, представляет собой аналогию шины: он прозрачно транслирует чтение/запись в определенном окне адресного пространства в пакетные обращения по шине, плюс еще умеет делать некие конфигурационные обращения. В общем, структурно даже несколько на PCI похоже, только без hotplug. То есть, после того, как сам VLYNQ поднят, можно вычислить базовый адрес регистров UART 16550 и он ничем не будет отличаться от такого же UART, встроенного в процессор. То есть, казалось бы, можно как-то приживить к работе с таким UART-ом обычные драйвера, вроде serial8250.

 

Теоретически, правда, есть пара нюансов:

1. Tсли линк у VLYNQ пропадет, то чтение через VLYNQ завешивает систему. То есть, по хорошему перед чтением чего-то нужно проверять линк на исправность (статус в локальном регистре контроллера VLYNQ). Но вот на практике никогда у нас линк не падал пока.

2. Адресное пространство шины VLYNQ вообще-то тоже 32-битное. Но так как оно доступно через окошко в адресном пространстве процессора, то единовременно видно только около 64М адресов, которые мапятся через регистр страниц. То есть, по хорошему, обращение драйверов к регистрам устройства должно вестись через spinlock, ассоциированный с драйвером шины VLYNQ.

3. Прерывания по VLYNQ идут как специальный пакетик между пакетами данных. Хотя контроллер VLYNQ поддерживает 32 бита флагов прерываний и умеет сам выделять наиболее приоритетный флаг, процессору он показывает только одно прерывание, собственно от контроллера VLYNQ. То есть, нужно как-то уметь воткнуть между обработчиком прерывания стандартного драйвера UART и собственно UARTом обработчик прерывания VLYNQ.

 

Почитав linux device drivers 3-го издания я так и не смог до конца уяснить, требует ли новая шина написания новых драйверов, если устройства имеют стандартный интерфейс управления. Точнее говоря, из повествования следует, что требует, если я устройство зарегистрирую именно на этой шине. С другой стороны, теоретически же можно сам драйвер шины написать так, что он найдет устройства UART на шине VLYNQ, но зарегистриует их как простые platform_device. И тогда они окажутся на шине platfrom_bus, где подбор драйверов идет просто по имени. Так делать можно, или это грабли?

 

По поводу прерывания. В ядре 2.6.37 есть исходничек drivers/vlynq/vlynq.c. К сожалению, он нам не подходит целиком, так ка заточен на одно устройство peer-to-peer, да и применялся он, судя по всему, только для arch/mips/ar7. Но вот там прерывания интересно сделаны. 32 прерывания от VLYNQ просто замаплены на диапазон номеров прерываний выше контроллера прерываний.

static irqreturn_t vlynq_irq(int irq, void *dev_id)
{
        struct vlynq_device *dev = dev_id;
        u32 status;
        int virq = 0;

        status = readl(&dev->local->int_status);
        writel(status, &dev->local->int_status);

        if (unlikely(!status))
                spurious_interrupt();

        while (status) {
                if (status & 1)
                        do_IRQ(dev->irq_start + virq);
                status >>= 1;
                virq++;
        }

        return IRQ_HANDLED;
}

Короче, обработчик прерывания VLYNQ, похоже, дергает сам обработчики виртуальных прерываний. То есть, можно зарегистрировать несколько platform_device, в ресурсах которых заказать прерывания с номером, соответствующим диапазону vlynq, и обработчик основного прерывания от vlynq сам передаст прерывание драйверу UART. И тогда, по идее, стандартный драйвер должен отработать.

 

Еще есть вопрос, можно ли иным способом повторно использовать код обычного драйвера UART? Ну, например, написать обертки ко всем его функциям, чтобы учитывать специфику шины (spinlock'и, проверки линка и пр).

 

[SM 0]

по поводу vlynq - тут не подскажу.

 

а вот по поводу уарта - все это одним мановением левого пальца - если это "8250.c" - в структуре plat_serial8250_port порта есть пойнтеры на ф-ции serial_in и serial_out, определив которые (на соотв. ф-ции нижележащего драйвера шины VLYNQ), драйвер уарта будет обращаться к портам уарта через них (при этом неважно, какой там UPIO_xxx стоит, эти ф-ции пересиливают флаги UPIO_). Тоже касается IRQ - передается в этой же структуре, и передать именно виртуаьный IRQ, который дернет драйвер VLYNQ.

[vpd 0]

Ну, допустим. Но ведь чтобы переопределенные serial_in, serial-out заработали, придется все равно регистрировать устройство как platform_device, так? Система то должна к нему драйвер поискать.

[SM 0]

Ну, допустим. Но ведь чтобы переопределенные serial_in, serial-out заработали, придется все равно регистрировать устройство как platform_device, так? Система то должна к нему драйвер поискать.

 

Это забота драйвера шины. Гляньте, например, на i2c - i2c_register_board_info(...), или как драйвера SPI делают - ну а переопределять уж Ваша забота, при заполнении platform_data на каждый уарт, который передастся через драйвер шины драйверу уарта, когда тот его регистрировать будет. Вам по аналогии с I2C надо писать некий vlynq_register_board_info

[vpd 0]

Поглядел два примера:

1) i2c_register_board_info -- drivers/i2c/{core.c, board_info.c}

2) mdio_bus -- drivers/net/phy/{mdio_bus.c, phy.c, phy_device.c}

 

По итогам получается следующее:

1) платформа регистрирует ресурсы устройства (i2c-adapter, mdio_bus)

2) драйверу дергается функция probe

3) драйвер проверяет, что периферийное устройство есть, и регистрирует само устройство в системе.

4) Функция регистрации запускает сканирование шины, либо сканирование ресурсов, статически привязанных к шине (board_info)

5) Появление новых ресурсов снова дает поиск драйверов, прилепленных к шине, вызов для них probe и т.д.

 

То есть, получается, драйвер VLYNQ должен определить, что за устройство реально в него воткнуто, а затем самостоятельно зарегистрировать ресурсы новых устройств. Вопросы:

1) В контексте какого процесса вызываются функции probe драйвера? Правильно ли я понимаю, что это может быть либо в контексте инициализации ядра до вызова /init, либо в контексте вызова утилиты insmod, если драйвер собран в модуль, либо еще как-то там через udev если он будет по hotplug'у подцеплен?

2) Можно ли регистрировать устройство на шине platform_bus, если реально ресурсы устройства принадлежат шине vlynq? Не несет ли это в себе какие-то подковерные проблемы? Или системе вообще пофигу на подчинение шин?

 

Например, если я хочу поднять простой UART с помощью драйвера serial8250, то мне нужно либо зарегистрировать именно platform_device с именем serial8250, либо писать драйвер порта для работы с шиной VLYNQ. Второе, может даже и правильнее, однако дольше в реализации.

Если же выбрать первое, то устройству UART придется ткнуть в ресурсы, которые целиком в ведении контроллера VLYNQ.

 

[SM 0]

А зачем все эти трудности? Вам реально PnP нужен на VLYNQ?

 

Сделайте проще. По аналогии с I2C. в board_xxxx.c создаете структурку, в которой список всего того, что на Вашей шине висит. Его отдаете драйверу vlynq (пишете соотв. vlynq_register_board_info) - оно по списку вызывает все probe для всех девайсов. Далее, делаете в драйвере VLYNQ функции типа vlynq_dev_iowrite и vlynq_dev_ioread. Которые обеспечивают доступ к регистрам того, что на шине висит. Их статически, через инициализационную структуру, передаете в platform_data (поля serial_in и serial_out) драйверу 8250, после чего драйвер 8250 работает с своим 8250 функциями драйвера шины, что корерктно с точки зрения того, кому чьи ресурсы даны. И драйвер 8250 не требует никакой доработки, только реализовать пару ф-ций в драйвере vlynq.

 

Ну а если еще и модулем грузить.... И PnP... Вам шашечки, или ехать?

 

Если хотите совсем просто и быстро - вообще драйвер vlynq не трогайте и не подключайте, напишите прямо в инициализации борды получение ресурсов VLYNQ, и свои ф-ции serial_in и serial_out, работающие через VLYNQ, там же рядом в файле борды. И регистрируйте сразу драйвер 8250, с передачей ф-ций доступа через platform_data ему. Но тут с reuse потом будут проблемы :)

[vpd 0]

Да дело не в PNP. Я хочу, собственно, двух вещей:

1) минимальную защиту от дурака сделать. То есть, что бы при изменении прошивки ПЛИС для другого проекта с другим набором периферии система ругнулась и не подняла старые устройства на VLYNQ.

2) Чтобы не надо было собирать ядро по всяком мало-мальски пустяковому поводу. Проблема, естественно, не в том, чтобы его собрать, а в том, что система поддержки изделий после поставки должна быть как-то унифицирована. И переделка всего ядра - это формально слишком большое изменение, которое потребует тестирования всей системы. При замене только стандартного модуля можно говорить о тестировании подсистемы.

 

Про шашечки изречение я не понял, я пока спросил про то, как устроен стандартный путь в линукс, когда требуется повторно использовать уже имеющийся код драйвера с новой шиной. Или стандартный путь - это шашечки и есть? :)

 

Что касается структур типа board_info, и, если смотреть глубже, вообще встраивания описания железа платы непосредственно в ядро, то налицо тенденция отказа от этой практики и замены ее на передачу описателя device_tree в виде внешней структуры как параметра запуска ядра. Придумано именно для унификации ядер и упрощения себе и пользователю жизни впоследствии. Пока что это не наш путь, так как еще пока не доделаны ядра для прочих кристаллов семейства, а все те, что есть, конфигурируются в рантайм. Слишком много работы, и это задача не первого этапа.

 

В отношении vlynq наш путь заключается в том, чтобы создать полноценную инфраструктуру управления шиной и устройствами на ней. Например, для 8250 нужно указать прерывание, но реально VLYNQ имеет свою подсистему прерываний, для управления которой нужно зарегистрировать в ядре еще один irq_chip. То есть в той или иной степени драйвер шины нужен, и "просто и быстро" не сделать. Кроме того, нам нужен еще драйвер собственно главного сопра на ПЛИС, который будет уметь делать трансферы по VLYNQ со скоростями до 35 МБ/с, и это естественно будет уже DMA, а не жалкие там обертки воде ioread/iowrite.

 

Пока что мне видится такая схема:

1) Регистрируем ресурсы для драйвера vlynq_bus.

2) запускаем драйвер, он регистрирует устройство vlynq_bus типа platform_device, определяет функции чтения-записи vlynq_шины, создает обработчик прерывания для шины.

3) Этот же драйвер сканирует удаленное устройство и регистрирует в системе первое и единственное vlynq_device с dev_id, равное прочитанному из конфигурационного пространства Vlynq удаленного устройства.

4) Мы делаем insmod и втыкаем в систему драйвер в виде модуля. который говорит, что он знает и поддерживает устройство с нужным dev_id.

5) Драйвер просто декодирует dev_id и регистрирует в системе перечень новых ресурсов. Ресурсы UART регистрируются в виде platform_device, ресурсы для собственных драйверов регистрируются как vlynq_device.

6) Система сама подключает драйверы UART с шины platform_bus к новым устройствам UART.

7) Мы делаем insmod и втыкаем в систему драйверы новых устройств для своих прикладных задач. Система связывает их с устройствами, делает probe и стартует драйвер для приложений.

8) Для приложений появляются интерфейсы через /dev, /sys или /proc и прикладные программы начинают работу с ними.

 

Это правильный путь?

[SM 0]

Да, путь в общем правильный. Только я не знаю, как при работе через insmod передать драйверу уарта ссылки на функции чтения/записи через драйвер vlynq шины - там ведь нет platform_data. Я пока не ходил путем с insmod, но, боюсь, что это потребует и патча для собственно драйвера 8250. Поэтому, на мой взгляд, сначала надо сделать драйвер vlynq_bus со статическим описанием периферии, подключенной к шине, без чтения всяких dev_id, собираемый внутрь ядра - и работу непатченного 8250 через него. (а если например через этот уарт загрузочная консоль? Какой такой inbsmod...). Вот это я называю "ехать". И когда оно заработает, уже наводить "шашечки" - делать поддержку insmod, PnP, и прочих рюшечек, облегчающих жизнь при тестировании и т.д.

[vpd 0]

Хм. А почему нет? Что мне мешает сделать точно такой-же вызов register_platform_device из драйвера устройства VLYNQ и поместить туда указатель на platform_data именно для serial8250? А сами функции можно сделать прямо в драйвере устройства как обертки для функций, предоставляемых собственно драйвером шины.

 

Со статическим описанием ресурсов UART я уже сделал. В целом оно дышит, пока немного криво, так как я сам UART пока кривой собрал в ПЛИС, но это к теме не относится :) Ну и пока с прерыванием разбираюсь, какие функции надо сделать для irq_chip, какой тип самим прерываниям сделать, и можно ли динамически выделить еще некоторый набор номеров irq или надо статически под них таблицу расширять?

 

Сами UART'ы нам нужны для внешних устройств, консолей для них не будет никогда. Для консолей есть два родных UART'а прямо в SOC. Но есть проекты, где нужно до 6 UART, причем иногда в полудуплексном исполнении RS-485. У меня для этого дела написан кор на VHDL, который 1) умеет управлять третьим состоянием выходного драйвера, 2) умеет сигналы DTR и RTS использовать для конфигурации типа порта: полудуплекс или полный дуплекс и ленивый/неленивый TXEN (для полного дуплекса RS-422). В итоге можно прямо через stty рулить конфигурацией драйвера порта.

 

В общем, программу минимум я уже почти выполнил до рюшечек я уже почти добрался, поэтому озаботился вопросами архитектуры. К сожалению, не хватает бэкграунда в в виде best practices. А просто ковыряя ядро можно всякой муры начитаться из рудиментов прошлого.

[SM 0]

Хм. А почему нет? Что мне мешает сделать точно такой-же вызов register_platform_device из драйвера устройства VLYNQ и поместить туда указатель на platform_data именно для serial8250? А сами функции можно сделать прямо в драйвере устройства как обертки для функций, предоставляемых собственно драйвером шины.

Как я понимаю, в принципе на шине могут быть не только уарты, в разные девайсы, и платформ-даты у них по формату разные. Поэтому надо, чтобы каждый из таких драйверов сам знал, что если он нашине vlynq, и в конфиге есть шина vlynq вообще (по #if, чтобы исходник собирался и без vlynq вообще для других систем) то должен использовать функции работы через vlynq. Это для insmod. А статически проще конечно, когда все платформ-даты статически заданы.

 

Ну и пока с прерыванием разбираюсь, какие функции надо сделать для irq_chip, какой тип самим прерываниям сделать, и можно ли динамически выделить еще некоторый набор номеров irq или надо статически под них таблицу расширять?

если это вопрос, и я его правильно понял, то он решен в дровах gpio, там этих irq немерено объявляется. То есть, по аналогии. Или это просто размышления вcлух по теме :)

[vpd 0]

Как я понимаю, в принципе на шине могут быть не только уарты, в разные девайсы, и платформ-даты у них по формату разные.

Могут. Но вот для platform_bus определена такая функция match, которая подбирает драйвер по имени устройства:

static const struct platform_device_id *platform_match_id(
                        const struct platform_device_id *id,
                        struct platform_device *pdev)
{
        while (id->name[0]) {
                if (strcmp(pdev->name, id->name) == 0) {
                        pdev->id_entry = id;
                        return id;
                }
                id++;
        }
        return NULL;
}

/**
* platform_match - bind platform device to platform driver.
* @dev: device.
* @drv: driver.
*
* Platform device IDs are assumed to be encoded like this:
* "<name><instance>", where <name> is a short description of the type of
* device, like "pci" or "floppy", and <instance> is the enumerated
* instance of the device, like '0' or '42'.  Driver IDs are simply
* "<name>".  So, extract the <name> from the platform_device structure,
* and compare it against the name of the driver. Return whether they match
* or not.
*/
static int platform_match(struct device *dev, struct device_driver *drv)
{
        struct platform_device *pdev = to_platform_device(dev);
        struct platform_driver *pdrv = to_platform_driver(drv);

        /* match against the id table first */
        if (pdrv->id_table)
                return platform_match_id(pdrv->id_table, pdev) != NULL;

        /* fall-back to driver name match */
        return (strcmp(pdev->name, drv->name) == 0);
}

 

Ну то есть platform_data подбирается соответственно устройству и драйвер, который по имени подойдет, будет знать о структуре этих данных. так что проблем быть не должно, и я могу хоть динамически выделить память и настроить все структуры.

 

если это вопрос, и я его правильно понял, то он решен в дровах gpio, там этих irq немерено объявляется. То есть, по аналогии. Или это просто размышления вcлух по теме

 

Ага, поглядим. На самом деле уже почти все понял, вопрос только про выделение диапазона свободных номеров irq, для которых система будет регистрировать новые обработчики.

 

[SM 0]

Ну то есть platform_data подбирается соответственно устройству и драйвер, который по имени подойдет, будет знать о структуре этих данных.

Драйвер, который подойдет, ясное дело, что знает о формате своего "platform_data"... А вот откуда будет знать драйвер шины, когда будет регистрировать драйвер найденного на ней девайса, по какому смещению в этой структуре, абсолютно уникальной для каждого драйвера (она и обзывается то <driver_name>_board_info обычно, и опредена в хедере каждого драйвера), находятся места для указателей на read и write функции? И вообще, в 8250 они есть, а в других драйверах их может не быть, даже обычно нет. Это тогда уже надо систему PnP во всей красе поднимать...

[vpd 0]

Что-то пока накопал, что все прерывания живут в большой таблице дескрипторов от 0 до NR_IRQS-1. И для того, чтобы подвесить обработчик, нужно заранее зарезервировать в таблице дополнительные номера прерываний. Я то как-то надеялся, что номера можно выделять в рантайме.

 

 

 

А вот откуда будет знать драйвер шины, когда будет регистрировать драйвер найденного на ней девайса, по какому смещению в этой структуре, абсолютно уникальной для каждого драйвера (она и обзывается то <driver_name>_board_info обычно, и опредена в хедере каждого драйвера), находятся места для указателей на read и write функции?

 

Не понял. Драйвер шины регистрирует устройство _своей_ шины (VLYNQ) и цепляет к ней устройство с dev_id, какой прочтет из самого устройства (FPGA). Дальше драйвер FPGA, вставленный insmod'ом, увидит свое устройство (match вернет 0), и когда будет делать probe, сообразит, что таком-то dev_id, соответствуют, скажем, два UART'а. Для них драйвер создаст структуры platform_device, platform_data, заполнит их и дернет register_platform_device. А указатели в них он вставит на свои собственные функции-обертки, которые будут просто ссылаться на подобные функции драйвера шины vlynq_bus. А драйвер шины эти функции объявит как экспортируемые модулем драйвера шины. Вот как-то так. Или это уже и есть PnP во всей красе?

[SM 0]

Ну, то есть, Вы хотите для всех-всех устройств, которые теоретически можно повесить на vlynq, и которые сейчас поддержаны в ядре линукса (имеют драйвера), иметь некий список сопоставления их dev_id с какими то функциями по заполеннию их board_info (которые для каждого драйвера устройства, а НЕ ШИНЫ, свои)? Короче, чтобы драйвер vlynq заранее знал о всех драйверах всех устройств, которые могут воткнуть в эту шину? Это не PnP... Это какое то новое веяние в линуксостроении... Получается, что для поддержки нового устройства на шине надо добавлять информацию о нем и о том, что он хочет в своем board_info в драйвер шины. Но это не логично - для добавления нового устройства должно быть достаточно написать новый драйвер, а драйвер шины не трогаит.

 

А "PnP во всей красе" - это 8250_pnp.c, это например в rtc/rtc_cmos.c, и сами его недра в drivers/pnp.

 

Для них драйвер создаст структуры platform_device, platform_data, заполнит их и дернет register_platform_device.

Вот как Вы себе это представляете в реализации? Откуда драйвер шины узнает, что для UARTа эта структура называется "struct plat_serial8250_port" и имеет по смещению XXX от начала поля serial_in и serial_out, где надо передать ф-ции обмена с девайсом через шину, а какой нибудь дядя вася из ЮАР через пару лет напишет драйвер своего супердевайса, который тоже может работать с VLYNQ, и у него структура будет называться "struct super_device_board_info" и там будут поля write_reg и read_reg, аналогичные по назначению serial_in/out у 8250, но совсем по другому смещению. То есть, по-Вашему, этот дядя вася будет вынужден еще и драйвер шины пропатчить, вписав в список свой драйвер и добавив туда функцию заполнения board_info для себя любимого? Ну или хотя бы этот список как-то передавать через platform_data самому драйверу шины... Если, конечно, он тоже не по insmod подключается.

 

или вообще это на уровне udev решать. Драйвер шины ему послал "обнаружено то, то и это", а udev сам решит, что с ними делать и как.

[vpd 0]

Ну, то есть, Вы хотите для всех-всех устройств, которые теоретически можно повесить на vlynq, и которые сейчас поддержаны в ядре линукса (имеют драйвера)

 

Снова не понимаю Вас. LDM подразумевает, что:

1) Устройства регистрируются в системе на определенной шине.

2) Драйверы регистрируются в системе на определенной шине.

3) Автоматическое связывание устройства и драйвера делается в рамках шины одного типа.

То есть, для того, чтобы UART завелся на шине VLYNQ, должен быть написан специальный драйвер, который зарегистрируется на шине VLYNQ и найдет там свое устройство. Исходный вопрос как раз и сводился к тому, есть ли какой-нибудь стандартный способ связывания имеющихся драйверов от старых шин с новыми шинами.

 

иметь некий список сопоставления их dev_id с какими то функциями по заполеннию их board_info (которые для каждого драйвера устройства, а НЕ ШИНЫ, свои)?

Вот посмотрите, и в 8250_pci.c, и в 8250_pnp.c большая часть текста посвящена перечислению поддерживаемых конфигураций а-ля board_info. Например, в 8250_pci.c все бы хорошо, и UART в общем-то почти всегда стандартный, однако же отличаются количество портов в одном BAR'е, смещение между соседними базовыми адресами, частота бодового генератора. И в итоге - длиннющая простыня настроек.

Так что в линуксостроении полно таких приемчиков. Но я то как раз и не так собирался делать. Попробую еще раз.

 

1) Для VLYNQ пишется драйвер шины. Он ничего не знает о конкретных устройствах на шине, но знает, что у каждого есть свой ID. Для лучшего понимания его архитектуры мыслите его как шину PCI с одним единственным слотом.

2) При старте драйвер шины просто поднимает шину, видит там одно устройство и регистрирует его на шине VLYNQ. И все.

3) Для этого ID пишется маленький мини-драйвер, который находит на ней свое устройство по ID, опознает его, и регистрирует ресурсы всех коров внутри ПЛИС как некие platform_device, например. Именно в этом драйвере сидят все аналоги board_info, а не в драйвере шины и не в ядре. Если пересобрать прошивку для ПЛИС и сменить там ID, но система просто не подберет драйвер, в системе не появятся ресурсы. В этом и есть "защита от дурака" и уход от ненужной сборки всего ядра.

4) Как только система видит новые устройства, добавленные мини-драйвером на шину platform_bus, она сама находит нужные драйверы и запускает их. При этом мини-драйвер может создать любые нужные platftrofm_data или другие структуры, необходимые для правильной настройки устройства.