Поддержка шины TDM в ядре Linux

Поводом для написания данного тезиса послужила наша работа по реализации
поддержки стандарта TDM в ядре Linux. Мы хотим рассказать вам об этом
стандарте, о том, почему мы решили реализовать его поддержку и какие это
открывает перспективы для других разработчиков и рядовых пользователей
ядра Linux.

Вообще говоря, TDM – это не совсем стандарт, это скорее принцип,
подразумевающий временное разделение информационного пространства канала.
TDM расшифровывается как Time Division Multiplexing, что следует понимать
примерно как мультиплексирование посредством разделения во времени. Все
просто: ряд устройств висят на одной шине и каждое из них ждет своей
очереди для отправки данных. В отличие от некоторых других реализаций
общей шины, эти устройства никогда не пытаются и в принципе не могут
пытаться передать свои данные одновременно, потому что у каждого
устройства есть свой так называемый time slot, и каждое конкретное
устройство может принимать или передавать данные только в пределах данного
тайм-слота, то есть некого промежутка времени.

Кроме тайм-слота, в рамках данной концепции существует более общая
временная велечина назывемая кадром или фрэймом. Фрэйм – это то, что
объединяет все тайм-слоты, т.е. за период в один фрэйм все устройства
зарегистрированные на шине имеют свои промежутки времени для обмена
данными, и принцип TDM гарантирует, что в каждый конкретный момент вермени
только одно устройство имеет право работать с шиной.

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

Что это означает на практике? На практике данный подход имеет свои
преимущества и конечно же недостатки. Преимущества, это в первую очередь
соответствие требованиям realtime, то есть данная шина обеспечивает
нулевую задержку и стопроцентную гарантию передачи данных, даже в том
случае, если одновременно с этой шиной работают все имеющиеся в наличии
устройства. Достигается это за счет того, что тактовая частота TDM шины
оказывается достаточной для передачи данных генерируемых всеми
устройствами, которые на ней находятся. В случае если речь идет о
аудио-устройствах – это не представляет никакой проблемы, поскольку объем
генерируемых ими данных очень невелик.

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

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

Вообще говоря, стандарт TDM очень старый и возможно тем, кто был знаком с
ним раньше покажется странным, что его реализация внезапно появляется во
вполне современных устройствах, а его поддержка находится на стадии
аппрува перед добавлением его в ядро Linux. По-видимому, это как раз тот
случай, когда некий стандарт или концепция прижившись в одной сфере,
оказывается более чем востребованной уровнем ниже. Когда-то очень давно, в
80-х годах двадцатого века, TDM нашел широкое применение для соединения
телефонных станций между собой, а теперь тот же принцип используется для
соединение динамика и микрофона с процессором мобильного телефона.
Забавно, правда? На самом деле, подобных примеров очень много, но к
сожалению, объем статьи не позволяет мне рассказать даже о самых
примечательных из них.

С другой стороны, в каком-то смысле, поддержка TDM существует в ядре Linux
довольно давно, но никогда прежде никто не пытался вынести поддержку этой
концепции в отдельный фрэймворк, по аналогии с тем, как это сделано для
других шин и стандартов. Теперь же, когда данная реализация пройдет все
необходимые проверки и будет добавлена в код ядра, у других разработчиков
появиться прекрасная возможность не изобретать велосипед каждый раз при
написании драйвера для своего устройства, а использовать API
предоставляемый TDM фрэймворком.

Данный фрэймворк позволяет абстрагировать взаимодействие с шиной TDM и
привести это взаимодействие к некому единому стандарту, лишь по мере
необходимости добавляя поддержку конкретных контроллеров, а так же прочих
устройств, которые могут быть к данной шине подключены. То есть
использование данной реализации, является практикой повторного
использования кода, которая является одним из базовых механизмов
экосистемы OpenSource.

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

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

Говоря о существующих стандартах, было бы уместно привести примеры того,
как именно данная концепция используется в реально существующих
устройствах. А используется она очень широко: преимущественно это
устройства ориентированные на работу со звуком или содержащие работу со
звуком в своем функционале. Как правило, применение данного стандарта
особенно оправданно там, где нужно работать с большим количеством
относительно медленных сигналов, т.е. идеальным примером является звуковая
карта с большим количеством входов и выходов. Использование TDM позволяет
обойтись одной единственной шиной даже для весьма внушительного кличества
входов и выходов. И это не голая теория, в реальности очень многие
звуковые карты действительно содержат в своем устройстве такого рода шину.
Еще одним, не менее уместным применением данной шины являются DAQ boards,
т.е. платы захвата аналоговых данных, содержащие большое или даже огромное
количество входов. Данные платы являются узкоспециализированными и как
правило проприетарными устройствами, поэтому нам мало известно о том, как
именно они устроены, но если сигналы ими отрабатываемые слишком быстрые
для расширения количества входов простым мультиплексированием, то шина TDM
может быть одинм из самых оптимальных решений.

Ну и конечно нам хотелось бы рассказать о нашем устройстве, в работе
которого так же участвует шина TDM. Данное устройство относится к классу
CPE, что расшифровывается как Costumer Premise Equipment. На деле эта
формулировка означает, что часть функционала, который мог бы располагаться
на стороне провайдера, ATC или оператора кабельного телевидения, может
быть перенесена на сторону абонента, причем со значительной выгодой как
для для абонента, так и для всех перечисленных поставщиков услуг. Выгода
это выражается в совокупном удешевлении оборудования, в упрощении
принципов доставки контента и конечно же в расширении доступного
пользователю функционала. Одним из ключевых компонентов данного
функционала является конечно же телефония, а точнее – IP-телефония. В
качестве основы для реализации VoIP подсистемы мы выбрали широко
распространенное, стабильное и функционально развитое решение – PBX
Asterisk. Наша система построена на базе Linux-дистрибутива OperWRT,
поэтому в плане интеграции в программную платформу никаких проблем не
возникло – asterisk есть в репозитории данного дистрибутива.

А вот с поддержкой наших аппаратных средств возникли определенные
трудности. В качестве аппаратной платформы наша система использует SoC
Marvell Kirkwood, в составе которого есть ряд подсистем, драйверы для
которых реализованы исключительно в рамках поставляемого с данным чипом
SDK. Часть драйверов нам удалось перенести из данной SDK в инфарструктуру
OpenWRT и это было вполне оправданно, однако поддержка существующего на
чипе TDM на тот момент отсутствовала даже в составе SDK, не говоря уже про
mainline kernel. В свете этих фактов нами было принято решение начать
разработку собственного драйвера. В процессе работы над драйвером
выяснилось, что в новой версии SDK внезапно появилась поддержка данного
функционала, причем поддерживалась не только сама шина TDM, но и SLIC,
который был уже установлен на нашу плату и висел на этой шине. SLIC, это
subscriber line interface card, т.е. в сущности то самое аудио-устройство
использующее шину TDM – еще один удачный пример из жизни, где TDM
оказывается полезным.

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

Выглядит это примерно так: TDM фрэймворк обеспечивает поддержку некой
абстракции, а в рамках этой абстракции поддерживается конкретная
реализация TDM от Marvell и микросхема SLIC. Данное решение прекрасно
работает в нашем устройстве, а при желании можно без особых проблем
добавить поддержку любых других реализаций TDM и любых устройств,
совместимых с этой шиной.

Существование нашего фрэйморка в mainline kernel может существенно ускорить
дальнейшее развитие IP-телефонии на платформе Linux, а также даст нам
много других существенных бонусов, в виде более быстрой и качественной
разработки новых драйверов для звуковых карт, гарнитур, плат захвата
данных и многих других устройств, в которых используется эта простая,
надежная и крайне эффективная шина.