Поддержка USB в KolibriOS: что внутри? Часть 4: уровень поддержки каналов

Рассказ об уровне взаимодействия с хост-контроллерами растянулся на две ^[1] статьи ^[2] и всё равно оставил за кадром некоторые детали — которые, как я надеюсь, заинтересованный читатель может восполнить непосредственно из исходников ^[3]. Уровень поддержки каналов куда проще и в основном занят тем, что преобразует вызовы API для вышележащих уровней в нужную последовательность действий, включая блокировки, с нужным хост-контроллером.

Открытие канала

Функция USBOpenPipe из API, названная usb_open_pipe в коде pipe.inc ^[4], открывает новый канал по указанным характеристикам канала и «родительскому» каналу, где записаны характеристики устройства. Для этого она:

• выделяет пару структур *hci_pipe+usb_pipe, описывающих канал и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocPipe;
• выделяет пару структур *hci_gtd+usb_gtd, описывающих пустой дескриптор передачи и выравненных на контроллеро-специфичную границу, вызовом контроллеро-специфичной функции usb_hardware_func.AllocTD;
• заполняет указатели: в структуре канала копирует указатель на структуру контроллера и указатель на данные устройства, общие для всех каналов, из «родительского» канала; между структурой канала и структурой пустого дескриптора заполняет указатели туда-обратно; структуру пустого дескриптора делает единственным элементом двусвязного списка каналов;
• инициализирует мьютекс, который будет охранять все операции с этим каналом. Хотя вся обработка событий от USB-контроллеров происходит в потоке USB, про обращения к API нельзя сказать того же: чтение приложением файла с USB-флешки инициирует постановку передачи — и даже не одной — в очередь в контексте потока приложения. Чтобы новая передача не мешала USB-потоку обрабатывать завершение старой передачи, и нужен этот мьютекс;
• захватывает мьютекс набора каналов устройства и убеждается, что устройство ещё не отключено;
• вызывает контроллеро-специфичную инициализацию usb_hardware_func.InitPipe, охраняемую мьютексом, глобальным для контроллера;
• добавляет новый канал в набор каналов устройства и отпускает мьютекс набора каналов;
• при ошибке на одном из этапов откатывает все предыдущие этапы. Поскольку откатить контроллеро-специфичную инициализацию сложнее всего, она сделана на последнем этапе, после которого ошибок быть не может.

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

Здесь в игру вступает планировщик scheduler.inc ^[5]. Он как раз и выбирает один из списков каналов прерываний, а также убеждается, что для нового канала «достаточно места». Я напомню, что в каждом фрейме FullSpeed-шины под периодические передачи нельзя использовать более 90% времени, а в каждом микрофрейме HighSpeed-шины — более 80% времени.

Здесь я должна отметить, что если вы зачем-то пишете реализацию USB, которая должна работать в ваших условиях, на планировщике можно серьёзно сэкономить. Вам придётся в том или ином виде реализовать всё остальное, что описано в этой серии статей, но при отсутствии большой нагрузки можно вместо полного дерева обойтись всего одним списком каналов прерываний, обрабатываемым каждый фрейм/микрофрейм. Чуть более экономная схема, не слишком усложняющая реализацию, — один список каналов для каждого интервала обработки 1, 2, 4, 8, 16, 32 фреймов. Пока не нужно одновременно обрабатывать более одного устройства с большим трафиком на один хост-контроллер, такой подход ничем не уступает полноценному планировщику. Простая схема «сломается» в некоторых специфичных конфигурациях с двумя или более изохронными каналами FullSpeed-устройств или тремя или более изохронными каналами HighSpeed-устройств, но, быть может, никто и не будет запускать вашу реализацию в столь специфичных условиях?

Если же вы пишете реализацию USB, которая должна работать везде и всегда, планировщик вам тоже придётся написать.

Оценка времени транзакции

Хост-контроллер скрывает в себе реализацию всех этих деталей транзакции, для планирования достаточно лишь знать, сколько времени транзакция займёт. Время зависит от типа транзакции, направления транзакции и скорости устройства.

• Транзакция чтения по прерыванию состоит из пакета с токеном к устройству, ожидания ответа от устройства, пакета с данными от устройства, паузы после принятого пакета, пакета с обратной связью к устройству, паузы после отправленного пакета.
  • HighSpeed-шина: 68 бит в первом пакете, 736 бит ожидания, 40+(7/6)*8*(размер данных+3) бит во втором пакете, 8 бит паузы, 49 бит в последнем пакете, ещё 88 бит паузы — итого 989 + 8*(7/6)*(размер данных+3) бит максимум.
  • FullSpeed-шина: 39 бит в первом пакете, 18 бит ожидания, (401/400)*(11+(7/6)*8*(размер данных+3)) бит во втором пакете, 2 бита паузы, 20 бит в последнем пакете, ещё 2 бита паузы — итого 93 + 2807/300*(размер данных+3) бит максимум.
  • LowSpeed-шина: 16 FS-бит преамбулы к первому пакету и 4 FS-бита на реакцию хабов, 8*39 FS-бит в первом пакете, 8*18 FS-бит ожидания, (406/50)*(11+(7/6)*8*(размер данных+3)) FS-бит во втором пакете, 8*2 FS-бита паузы, 16 FS-бит преамбулы к последнему пакету и 4 FS-бита на реакцию хабов, 8*20 FS-бит в последнем пакете, ещё 8*2 бита паузы — итого 778 + 5684/75*(размер данных+3) FS-бит максимум.
• Транзакция записи по прерыванию состоит из пакета с токеном к устройству, паузы после отправленного пакета, пакета с данными к устройству, ожидания ответа от устройства, пакета с обратной связью от устройства, паузы после принятого пакета. Отличие от чтения, не считая порядка слагаемых, только в направлении передачи.
  • HighSpeed-шина: те же 989 + 8*(7/6)*(размер данных+3) бит максимум.
  • FullSpeed-шина: множитель 401/400 «переезжает» от пакета данных к пакету обратной связи, итого 93 + 28/3*(размер данных+3) бит максимум.
  • LowSpeed-шина: множители 406/50 и 8 в двух пакетах данных и обратной связи меняются местами, итого 778 + 224/3*(размер данных+3) FS-бит максимум.
• Изохронная транзакция чтения состоит из пакета с токеном к устройству, ожидания ответа от устройства, пакета с данными от устройства, паузы после принятого пакета
  • HighSpeed-шина: 68 бит в первом пакете, 736 бит ожидания, 40+(7/6)*8*(размер данных+3) бит во втором пакете, 8 бит паузы — итого 852 + 8*(7/6)*(размер данных+3) бит максимум.
  • FullSpeed-шина: 39 бит в первом пакете, 18 бит ожидания, (401/400)*(11+(7/6)*8*(размер данных+3)) бит во втором пакете, 2 бита паузы — итого 71 + 2807/300*(размер данных+3) бит максимум.
  • На LowSpeed-шине изохронные транзакции запрещены спецификацией.
• Изохронная транзакция записи состоит из пакета с токеном к устройству, паузы после отправленного пакета, пакета с данными к устройству, ещё одной паузы после отправленного пакета.
  • HighSpeed-шина: 68 бит в первом пакете, 88 бит паузы, 40+(7/6)*8*(размер данных+3) бит во втором пакете, ещё 88 бит паузы — итого 284 + 8*(7/6)*(размер данных+3) бит максимум.
  • FullSpeed-шина: 39 бит в первом пакете, 2 бита паузы, 11+(7/6)*8*(размер данных+3) бит во втором пакете, ещё 2 бита паузы — итого 54 + 8*(7/6)*(размер данных+3) бит максимум.
  • На LowSpeed-шине изохронные транзакции запрещены спецификацией.

Расщеплённые транзакции содержат три типа «элементарных» транзакций на двух шинах: транзакция Start-Split на HighSpeed-шине между хостом и TT, обычная транзакция на FullSpeed/LowSpeed-шине между TT и устройством, транзакция Complete-Split на HighSpeed-шине между хостом и TT. Время транзакции в середине отличается от времени такой же транзакции без TT только дополнительной паузой, вносимой TT и описанной в дескрипторе хаба с TT. Транзакции Start-Split и Complete-Split начинаются со специального пакета SPLIT размером 4 байта, не считая SYNC+EOP.

• Расщеплённая транзакция чтения по прерыванию и изохронная транзакция чтения. Транзакция Start-Split состоит из пакета SPLIT, паузы после отправленного пакета, пакета с токеном, паузы после отправленного пакета — итого 321 бит. Транзакция Complete-Split состоит из пакета SPLIT, паузы после отправленного пакета, пакета с токеном, ожидания ответа от устройства, пакета с данными, паузы после принятого пакета — итого 1017 + 8*(7/6)*(размер данных+3) бит.
• Расщеплённая транзакция записи по прерыванию. Транзакция Start-Split состоит из пакета SPLIT, паузы после отправленного пакета, пакета с токеном, паузы после отправленного пакета, пакета с данными, паузы после отправленного пакета — итого 449 + 8*(7/6)*(размер данных+3) бит. Транзакция Complete-Split состоит из пакета SPLIT, паузы после отправленного пакета, пакета с токеном, ожидания ответа устройства, пакета с обратной связью, паузы после принятого пакета — итого 1026 бит.
• Расщеплённая изохронная транзакция записи. Транзакция Start-Split имеет такую же структуру, как в случае транзакции записи по прерыванию, 449 + 8*(7/6)*(размер данных+3) бит. Транзакция Complete-Split отсутствует.

Планировщик

На FullSpeed/LowSpeed-шине за один фрейм может быть не более одной транзакции по одному каналу, передачи из более чем одной транзакции разбиваются на несколько фреймов. На HighSpeed-шине максимальное количество транзакций за микрофрейм может доходить до 3 и является одной из характеристик канала наряду с максимальным размером транзакции.

При открытии канала планировщик должен зарезервировать за каналом часть от 90% фрейма / 80% микрофрейма, исходя из наихудшего случая использования канала — предполагая максимально возможное число максимально длительных транзакций. Длительность транзакций описана в предыдущем разделе. Если зарезервировать часть канала не получается из-за того, что всё уже занято другими каналами, планировщик должен вернуть ошибку. Драйвер, обнаружив ошибку, может, например, попытаться договориться с устройством о снижении трафика за счёт чего-нибудь или сообщить пользователю (посредством управляющей программы), что в таких условиях работать невозможно.

Расщеплённые транзакции добавляют сложностей. Во-первых, резервировать и вести учёт нужно на двух шинах. Во-вторых, на FullSpeed/LowSpeed шине появляются микрофреймы: если транзакция Start-Split от хоста к TT приходит в микрофрейме N, то TT сможет начать эту транзакцию только в микрофрейме N+1, а вернуть результаты в транзакции Complete-Split — не раньше микрофрейма N+2. В-третьих, хотя максимум в 90% фрейма на все периодические транзакции в худшем случае остаётся, планирование на FS/LS-шине должно исходить из оптимистичной оценки без множителя 7/6 из-за вставки битов, спецификация USB2 в лице раздела 11.18 «Periodic Split Transaction Pipelining and Buffer Management» называет такую оценку «best-case budget» — это уменьшает шансы на то, что FS/LS-шина будет простаивать из-за того, что одна периодическая транзакция завершилась раньше рассчитанного, следующая периодическая транзакция сможет начаться не раньше следующего микрофрейма, потому что для неё ещё не пришли данные Start-Split транзакции, а для очередной непериодической транзакции в остатке текущего микрофрейма не хватает времени. Наконец, хост не знает, когда точно завершится транзакция, а буферы TT для хранения результатов не резиновые, так что транзакцию Complete-Split нужно планировать несколько раз — по одному в каждом микрофрейме, следующем после микрофрейма, в котором транзакция может завершиться. Конкретные требования озвучены в том же разделе 11.18: в составе транзакции по прерываниям, по бюджету начинающимся в микрофрейме N, должны быть запланированы одна транзакция Start-Split в микрофрейме N-1 и три транзакции Complete-Split в микрофреймах N+1,N+2,N+3. Изохронные транзакции чтения отличаются только тем, что могут занимать несколько микрофреймов N,...,L в бюджете, из-за чего транзакции Complete-Split нужно планировать в микрофреймах от N+1 до L+3 включительно. В изохронных транзакциях записи транзакций Complete-Split не предусмотрено, зато может быть несколько транзакций Start-Split: в одном микрофрейме на FS-шине умещается менее 188 байт, и если данных больше, то они будут разбиты на несколько транзакций Start-Split с ограничением 188 байт в одной транзакции.

Планировщик KolibriOS пытается достичь как можно более равномерного распределения зарезервированных частей в различных фреймах/микрофреймах, стремясь к тому, чтобы во фразе «в каждом фрейме/микрофрейме есть X или более свободного времени» число X было бы как можно больше. Если позднее появится канал, требующий внимания каждый фрейм/микрофрейм, большое значение X необходимо для успешного резервирования. Если не появится — время пригодится для непериодических передач.

Сначала планировщик выбирает реальный интервал, с которым хост-контроллер будет опрашивать канал. Это лёгкая часть задачи: выбрать из чисел 1, 2, 4, 8, 16, 32 максимальное, не большее заданного. Дальше нужно выбирать из всех списков с уже выбранным интервалом. Я возьму для примера USB1 и интервал в 8 фреймов. Тогда есть 8 вариантов: список каналов, обрабатываемый во фреймах вида 8k+0, ..., список каналов, обрабатываемый во фреймах вида 8k+7. Планирование повторяется каждые 32 фрейма; вариант 8k+0 в одном диапазоне планирования содержит 4 фрейма 0,8,16,24, в каждом из которых могут быть уже запланированы разные наборы каналов. Чтобы вычислить общее время, зарезервированное для периодических транзакций во фрейме, например, 24, нужно просуммировать данные по спискам уже открытых каналов, соответствующим 32k+24, 16k+8, 8k+0, 4k+0, 2k+0, каждому фрейму. Вычислив такое время для каждого из фреймов 0,8,16,24, планировщик берёт максимум и связывает его с вариантом 8k+0. Аналогично вычисляется максимальное время, зарезервированное под уже существующие каналы, для остальных вариантов 8k+1, ..., 8k+7. Лучший из вариантов — тот, у которого максимальное зарезервированное время меньше остальных, а свободное, соответственно, больше остальных. Выбрав лучший вариант, планировщик проверяет, что резервирование времени для нового канала не переполнит 90% фрейма, и назначает выбранный вариант новому каналу.

Планирование HighSpeed-транзакций в USB2 аналогично USB1 с двумя отличиями: вариантов в 8 раз больше за счёт микрофреймов; если есть несколько вариантов с одинаковым временем, то планировщик выбирает тот, который ближе к концу фрейма, чтобы минимизировать конфликты с расщеплёнными транзакциями.

Планирование расщеплённых транзакций в USB2 следует тем же принципам, но детали ещё сложнее. Варианты, где на хотя бы одной из шин невозможно зарезервировать достаточное время, отбрасываются ещё до сравнения. В качестве основного критерия качества варианта используется бюджет на FS-шине как более ограниченной. При равном бюджете планировщик выбирает вариант, ближайший к началу фрейма. Если и тогда остаются варианты, последним критерием выступает время на HS-шине, максимальное из всех Start-Split и Complete-Split транзакций.

Явное закрытие канала и отключение устройства

Функция USBClosePipe из API, названная usb_close_pipe в коде pipe.inc, закрывает указанный канал. Для этого она захватывает мьютекс набора каналов устройства, устанавливает бит «владелец отказался от канала», вызывает общую функцию закрытия канала usb_close_pipe_nolock, отпускает мьютекс набора каналов устройства и будит USB-поток, чтобы тот обработал изменение в списках каналов.

При отключении устройства контроллеро-специфичный код или драйвер хабов вызывает функцию usb_device_disconnected, которая захватывает мьютекс набора каналов устройства, проходит по всем каналам, для каждого вызывает общую функцию usb_close_pipe_nolock, предварительно запомнив, какой канал идёт следующим, в конце отпускает мьютекс набора каналов устройства. Будить USB-поток нет необходимости, поскольку он и так не спит, будучи занят выполнением этого кода.

Общая функция usb_close_pipe_nolock:

• захватывает мьютекс канала (возможно, подождав окончания постановки передачи в очередь);
• проверяет, что канал ещё не закрыт, и устанавливает бит «канал закрыт» (после чего новые передачи не будут добавляться в очередь — для этого и захватывается мьютекс);
• отпускает мьютекс канала;
• удаляет канал из набора каналов устройства;
• вызывает контроллеро-специфичную функцию usb_hardware_func.UnlinkPipe, охраняемую глобальным для контроллера мьютексом, которая удалит канал из соответствующего списка каналов и сообщит планировщику scheduler.inc об удалении канала.

Удалённый канал какое-то время ещё может обрабатываться контроллером, поэтому окончательное удаление происходит немного позже, когда контроллеро-специфичный код вызовет функцию usb_pipe_closed, которая:

• проходит по очереди оставшихся передач, вызывает callback-функции с ошибкой «канал закрылся» и освобождает все дескрипторы передач;
• если это не последний канал устройства и бит «драйвер отказался от устройства» установлен, то просто освобождает память, выделенную под структуры канала;
• если это не последний канал устройства и бит «драйвер отказался от устройства» сброшен, то добавляет канал в список каналов устройства, подлежащих освобождению;
• если это последний канал устройства, то вызывает функции DeviceDisconnected всех драйверов устройства, помечает адрес устройства на шине, если таковой был назначен, как свободный, освобождает память, выделенную под структуры канала, а также проходит по списку каналов устройства, подлежащих освобождению, и освобождает память, выделенную под них.

Передачи массивов данных и передачи по прерываниям

Такие передачи состоят из одного этапа, так что функция USBNormalTransferAsync из API, названная usb_normal_transfer_async в коде pipe.inc, проста: захватывает мьютекс канала, проверяет, что канал ещё не закрыт, создаёт передачу вызовом контроллеро-специфичной функции usb_hardware_func.AllocTransfer, указывая использовать направление, сохранённое в структуре канала при открытии, активирует передачу вызовом usb_hardware_func.InsertTransfer и освобождает мьютекс канала.

Управляющие передачи

Управляющие передачи состоят из двух или трёх этапов с данными, передаваемыми в различных направлениях, поэтому функция USBControlTransferAsync из API, названная usb_control_async в коде pipe.inc, несколько сложнее USBNormalTransferAsync.

Здесь контроллеро-специфичная функция usb_hardware_func.AllocTransfer вызывается дважды или трижды, по числу этапов. Направление передачи задаётся явно. Кроме того, явно задаётся ещё одна характеристика передачи — бит Toggle. Неизохронные транзакции в USB «красятся в два чередующихся цвета» для отслеживания ситуации, когда какой-нибудь пакет не дошёл до адресата. Для каналов прерываний и каналов массивов данных чередование сквозное по всем передачам: если передача закончилась на транзакции с Toggle=0, следующая передача начнётся с Toggle=1 и наоборот. В управляющих передачах бит Toggle сбрасывается с каждым новым этапом, как показано на рисунке.

Все статьи серии

Часть 1: общая схема ^[6]
Часть 2: основы работы с хост-контроллерами ^[1]
Часть 3: код поддержки хост-контроллеров ^[2]
Часть 4: уровень поддержки каналов

Автор: CleverMouse

Источник ^[7]