Управление потреблением: приостановка, возобновление и удаленное пробуждение

Подробности

Родительская категория: USB

Категория: Физический интерфейс USB

USB имеет развитую систему управления энергопотреблением. Хост-компьютер может иметь собственную систему управления энергопотреблением (power management system), к которой логически подключается и одноименная система USB. Программное обеспечение USB взаимодействует с этой системой компьютера, поддерживая такие системные события, как приостановка (suspend) или возобновление (resume). Кроме того, устройства USB могут сами являться источниками событий, отрабатываемых системой управления энергопотреблением хоста.

Все устройства USB должны поддерживать режим приостановки (suspended mode), в котором средний потребляемый от шины ток не превышает 500 мкА. Мощным устройствам, которые могут инициировать удаленное пробуждение, позволительно в этом режиме потреблять до 2,5 мА. Устройство должно автоматически приостанавливаться при прекращении активности шины. Приостановка выполняется всегда по инициативе хоста и может быть как глобальной, так и селективной. Возобновление (resume) может происходить по разным причинам и сценариям.

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

• по инициативе хоста — командой к корневому хабу, что приведет к сигнализации возобновления для всех подключенных к нему сегментов;
• по инициативе устройства — удаленным пробуждением (remote wakeup). Сигнал возобновления может подать любое устройство, которому управляющим запросом разрешена миссия «будильника». Этот сигнал воспринимается портом хаба, к которому подключено устройство-«будильник», после чего посылается хабом во все разрешенные порты («отражаясь» и на порт-источник сигнала) и на восходящий порт. Распространяясь таким образом, сигнал возобновления дойдет и до корневого хаба, который еще 20 мс транслирует этот сигнал на нисходящие порты, после чего завершает сигнализацию возобновления посылкой сигнала LS-EOP;
• по событию порта хаба (подключению или отключению устройства), которому управляющим запросом разрешена генерация удаленного пробуждения;
• сбросом шины, вызывающим реконфигурирование всех устройств.

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

• по инициативе хоста — посылкой к хабу управляющего запроса отмены Port_Suspend. Это приведет к сигнализации возобновления на данный порт в течение 20 мс, завершающейся посылкой сигнала LS-EOP. После этого хаб возобновляет трансляцию нисходящего трафика на этот порт, а через 3 мс устанавливает в своем регистре состояния данного порта признак завершения процедуры возобновления. За это время подключенное устройство успеет засинхронизироваться с маркерами кадров;
• по инициативе устройства — удаленным пробуждением. Здесь хаб, который ввел приостановку, ведет себя иначе: он не распространяет сигнал возобновления на другие порты (там могут находиться активно работающие устройства и передаваться трафик). Восприняв сигнал возобновления, хаб сам его посылает в течение 20 мс на тот же порт, затем посылает в него сигнал LS-EOP и через 3 мс устанавливает признак завершения возобновления для этого порта (сбрасывает бит Port_Suspend);
• по событию порта хаба (подключению или отключению устройства), которому управляющим запросом разрешена генерация удаленного пробуждения;
• сбросом шины, вызывающим реконфигурацию всех устройств.

Если на селективно приостановленном порте хаба происходит событие подключения-отключения, то этот порт из состояния suspended перейдет в connected или disconnected в соответствии с состоянием текущего подключения.

За селективной приостановкой какого-то порта хаба может последовать и общая приостановка данного хаба (глобальная или тоже селективная). Это не помешает распространению сигнала удаленного пробуждения вверх. Когда до хаба сверху дойдет сигнал возобновления, состояние suspended его портов, селективно приостановленных, сохранится — хост должен будет снять приостановку соответствующими запросами. Удаленное пробуждение автоматически снимет состояние suspended с порта, на который оно пришло.

Стандартные запросы к устройствам

Подробности

Родительская категория: USB

Категория: Устройства USB

Стандартные запросы относятся ко всем устройствам USB, хотя для ряда устройств есть исключения: управление альтернативными установками интерфейсов не требуется, если нет альтернатив; установка меток времени нужна (и возможна) только для устройств с изохронными точками. Стандартные запросы адресуются к EP0, признак стандартного запроса — в поле типа bmRequestType D[6:5] = 0. Типы и коды стандартных запросов приведены в таблице.

 

Таблица Стандартные запросы к устройствам

Запрос	bmRequestType	bRequest
Clear_Feature	00000000b 00000001b 00000010b	1
Get_Configuration	10000000b	8
Get_Descriptor	10000000b	6
Get_Interface	10000001b	10
Get_Status	10000000b 10000001b 10000010b	0
Set_Address	00000000b	5
Set_Configuration	00000000b	9
Set_Descriptor	00000000b	7
Set_Feature	00000000b 00000001b 00000010b	3
Set_Interface	00000001b	11
Synch_Frame	10000010b	12

 

Запрос установки адреса Set_Address адресуется только ко всему устройству, в поле wValue передается адрес, назначаемый устройству.

Запросы обращения к дескрипторам Get_Descriptor и Set_Descriptor адресуются только ко всему устройству. Здесь поле wValue в старшем байте содержит тип дескриптора (1, 2, 3, 6 или 7 для Get и только 1, 2 или 3 для Set), в младшем — индекс строки (для дескрипторов типа 3) или номер конфигурации (для дескрипторов типа 2 или 7). Поле wIndex используется только для строковых дескрипторов для задания языка (Languge ID). Поле wLength задает длину дескриптора. Если реальная длина считываемого дескриптора больше запрошенной, то считывается только его начало; если меньше, то устройство в транзакции возвращает только реальное количество байтов.

Запросы управления конфигурацией Get_Configuration и Set_Configuration также адресуются только к устройству. В запросе установки (Set) используется только поле wValue — в его младшем байте передается номер устанавливаемой конфигурации. В запросе чтения (Get) используется только поле wLength (= 1) — ожидается один байт ответа, содержащий номер текущей конфигурации.

Запросы управления альтернативными установками Get_Interface и Set_Interface адресуются к интерфейсу, номер которого указывается в поле wIndex. В запросе установки (Set) в младшем байте поля wValue передается номер альтернативной установки. В запросе чтения (Get) поле wLength (= 1) указывает на ожидание одного байта ответа, содержащего номер текущей альтернативной установки для данного интерфейса.

Запрос установки метки времени Synch_Frame, адресуемый к устройству, в поле wIndex содержит номер точки, к которой относится данная метка. Поле wLength (= 2) указывает на 2 байта передаваемых данных — номера кадра для данной метки.

Запрос чтения состояния Get_Status может адресоваться к устройству, интерфейсу или конечной точке. Здесь поле wIndex определяет номер объекта (интерфейса или точки, для устройства — ноль), поле wLength указывает число байтов ожидаемых данных состояния. Трактовка данных состояния зависит от адресата:

• в стандартном запросе состояния устройства (wLength = 2) определено значение лишь младших бит слова: D0 (Self Powered) — признак автономности питания (0 — питается от шины); D1 (Remote Wakeup) — возможность подачи сигнала удаленного пробуждения (0 — нет); D2 (Port Test): 1 — порт находится в режиме тестирования;
• чтение состояния интерфейса в стандартном запросе информации не дает (возвращает нули). Однако он может использоваться в запросе для класса; так, например, для принтеров этот запрос (при wLength = 1) возвращает байт состояния, аналогичный состоянию LPT-порта (принтер выбран, ошибка, конец бумаги);
• в стандартном запросе состояния конечной точки (wLength = 2) определено значение лишь младшего бита слова: D0 (Halt) — признак остановки конечной точки (на транзакции с ней устройство отвечает пакетом STALL).

Запросы управления свойствами Set_Feature (установить свойство) и Clear_Feature (сбросить свойство) также могут адресоваться к устройству, интерфейсу или конечной точке. Здесь поле wIndex определяет номер объекта (интерфейса или точки, для устройства — ноль), поле wValue задает номер свойства. Набор стандартных управляемых свойств невелик:

• управление возможностью подачи удаленного пробуждения (Device_Remote_Wakeup), адресат — устройство, wValue = 1;
• управление остановкой (блокировкой) конечной точки (Endpoint_Halt), адресат — конечная точка, wValue = 0. Остановленная (заблокированная) конечная точка будет на все транзакции отвечать пакетом STALL. Сброс признака останова разблокирует и инициализирует точку, включая начальную установку переключателя (Toggle Bit);
• управление тестовым режимом приемопередатчиков (Test_Mode), адресат — устройство, wValue = 2. Здесь используется и поле wIndex, определяющее выполняемый тест: 01 — Test_ J, 02 — Test_K, 03 — Test_SE0_Nack, 04 — Test_Packet, 05 — Test_Force_Enable. Значения 06–3Fh зарезервированы для стандартных тестов, C0–FFh отданы разработчикам устройств. Данным запросом можно только включить тест; для выключения теста устройство приходится выключать и включать питание устройства, поскольку управляющие запросы оно уже не воспринимает.

 

Общая информация

Подробности

Родительская категория: USB

Категория: Хабы USB

Хаб является ключевым элементом системы PnP в архитектуре USB. Хаб выполняет множество функций, в частности:

• обеспечивает физическое подключение устройств, формируя и воспринимая сигналы в соответствии со спецификацией шины на каждом из своих портов и транслируя трафик с восходящего порта на нисходящие и наоборот;
• обеспечивает управляемую информационную связь сегментов шины, включая и связь сегментов, работающих на разных скоростях. Каждому нисходящему порту может быть селективно разрешена или запрещена трансляция трафика;
• отслеживает состояние подключенных к нему устройств, уведомляя хост об изменениях — подключении и отключении устройств;
• обнаруживает ошибки на шине, выполняет процедуры восстановления и изолирует неисправные сегменты шины. Благодаря бдительности хабов неисправное устройство не может заблокировать всю шину;
• управляет энергопотреблением: подает питающее напряжение на нисходящие порты; селективно генерирует сигнал приостановки портов, транслирует эти сигналы в разных направлениях.

Структура хаба USB 2.0 приведена на рисунке. Хаб состоит из набора портов, контроллера хаба (устройство-функция USB, подключенная к внутреннему порту), повторителя, транслятора транзакций, маршрутизирующей логики портов и цепей управления подачей питания. Хаб USB 1.x проще: в нем отсутствует транслятор транзакций и логика маршрутизации нисходящих портов — они все подключаются к повторителю.

«Расширенный» хост-контроллер — EHC

Подробности

Родительская категория: USB

Категория: Хост USB

«Расширенный» хост-контроллер EHC (Enhanced Host Controller) был введен фирмой Intel для поддержки высокой скорости в USB 2.0. Его интерфейс — EHCI — описан в документе «Enhanced Host Controller Interface Specification for Universal Serial Bus», версия 1.0 опубликована в марте 2002 года. Контроллер EHC предназначен для работы с устройствами только на высокой скорости подключения к корневому хабу, при этом для устройств FS/LS, которые подключены через промежуточный хаб USB 2.0, контроллер EHC выполняет расщепленные транзакции. С теми портами корневого хаба, к которым непосредственно подключены хабы и устройства USB 1.x, работает контроллер-компаньон (UHC или OHC). Коммутацию портов и контроллеров осуществляет маршрутизирующая логика, входящая в состав корневого хаба USB 2.0. Обнаружением подключения устройств к корневому хабу занимается драйвер EHC через регистры EHC. Обнаружив подключение FS/LS-устройства, драйвер перекоммутирует данный порт на контроллер-компаньон, и с этого момента порт отдается в ведение компаньону и его драйверу. Компаньон и его драйвер могут и не «знать» о том, что они работают в составе контроллера USB 2.0. Для портов, остающихся в ведении EHC, эмулируется внешний хаб — ПО манипулирует портами, используя стандартные запросы к хабам USB.

Контроллер EHC имеет конфигурационные регистры PCI, операционные регистры ввода/вывода, отображенные на пространство памяти (memory mapped I/O) и использует область системной памяти для взаимодействия с драйвером. С точки зрения взаимодействия с драйвером EHC отчасти напоминает UHC, но высокая скорость передачи (480 Мбит/с) потребовала усиления интеллекта контроллера с целью уменьшения числа операций обмена между драйвером, памятью и контроллером. В EHC просматриваются многие идеи, заложенные в OHC. Структуры данных разработаны с учетом минимизации обращений к памяти. Все структуры должны размещаться в памяти так, чтобы они не пересекали границы четырехкилобайтных страниц памяти — это позволяет оптимизировать сосуществование OHC с виртуальной памятью, основанной на страничной переадресации, применяемой в процессорах x86.

В EHCI с точки зрения планирования транзакций передачи делятся на периодические (изохронные и прерывания) и асинхронные (управляющие передачи и массивы). Каждый из этих двух планов реализуется по-своему и может быть включен в работу и выключен. Контроллер начинает каждый микрокадр с выполнения периодических передач (если они разрешены), оставшееся от них время выделяется для выполнения асинхронных передач (аналогично UHC). За то, чтобы в микрокадре оставалось время для асинхронных передач, отвечает драйвер. Хост-контроллер аппаратно следит лишь за тем, чтобы транзакции не пересекали границу микрокадра: если контроллер «видит», что транзакция может не успеть завершиться к моменту EOF1, он ее не начнет. При этом возможна перестраховка, поскольку точное время исполнения транзакции заранее не известно (неизвестно, сколько придется вставить бит и каковы задержки в кабелях, хабах и устройстве).

Для всех передач с гарантированной доставкой (прерывания, управление и массивы) используются структуры данных qTD (Queue Element Transfer Descriptor), описывающие очереди буферов, обеспечивающие автоматическое упорядоченное исполнение потоков передач. В EHC под передачей понимается последовательность однотипных транзакций; ограничен лишь суммарный размер передаваемых блоков (20 Кбайт). Транзакции управления хост планирует как последовательность двух-трех «передач» (в терминах EHC). Драйвер может динамически (во время исполнения плана) добавлять новые передачи в очереди. Контроллер аппаратно поддерживает сигнализацию окончания блоков короткими пакетами: приняв короткий пакет, контроллер может пойти по альтернативной последовательности передач для данной очереди (то есть организуется условный переход). Для изохронных передач используются специальные структуры данных (iTD — Isochronous Transaction Descriptors для HS и siTD — Split-transaction IsochronousTransfer Descriptors для расщепления транзакций с FS-устройствами). Для изохронных передач на HS дескриптор может описывать передачу до 24 Кбайт данных, на FS — до 1023 байт.

Основой планирования периодических транзакций является список кадров (Frame List) на 1024, 512 или 256 вхождений. Базовый адрес и длина списка устанавливается программно, текущий элемент списка выбирается по счетчику кадров. Исполнение плана начинается в каждом микрокадре, таким образом, каждый текущий элемент списка выбирается 8 раз подряд, после чего контроллер переходит к следующему элементу. Элемент списка может указывать на iTD, siTD или заголовок очереди (QH), относящейся к прерываниям. Кроме того, он может указывать на специальные структуры (FSTN), используемые для обеспечения корректности отработки расщепленных транзакций около границы кадра. В элементе списка кроме собственно указателя имеется идентификатор типа структуры (Typ), на которую ссылается указатель (iTD, siTD, QH или FSTN), а также признак заглушкитерминатора (T). Все дескрипторы изохронных передач и заголовки очередей имеют «горизонтальный» указатель на следующую структуру, в котором также задается и тип (Typ) этой структуры, и признак заглушки-терминатора (T). Цепочка дескрипторов и заголовков очередей, начинающаяся от списка кадров, должна завершаться дескриптором (или заголовком), у которого установлен признак заглушки-терминатора (T). Только отработав такой дескриптор (или заголовок), контроллер приступает к исполнению плана асинхронных передач.

Для упрощения планирования расщепленных транзакций (они не должны пересекать границу кадра) контроллер организует фазовый сдвиг между кадрами шины (BFrame), которые видны хабам и устройствам по факту смены номера кадра в маркере SOF, и кадрами хоста (HFrame), которыми оперирует драйвер при построении планов и по которым выбираются периодические транзакции из списка кадров. Кадры шины отстают от кадров хоста на один микрокадр, более подробные пояснения (но не мотивы) приведены в спецификации EHCI. Для обслуживания расщепленных периодических транзакций имеется специальная структура (узел) FSTN, содержащая пару указателей: нормальный, обеспечивающий переход к следующей структуре (iTD, siTD, QH или FSTN), и обратный, который может указывать только на заголовок очереди. Нюансы планирования расщепленных транзакций здесь приводить не будем, с ними можно ознакомиться в спецификации EHCI.

Основой планирования непериодических транзакций является асинхронный список (asynchronous list), представляющий собой кольцо из заголовков очередей. В OHC регистр AsyncListAddr указывает на текущий элемент списка; к отработке этого элемента контроллер приступает, завершив отработку периодических передач в данном микрокадре (или сразу, если периодические передачи запрещены или отсутствуют). Далее, по мере отработки очередей, контроллер заносит в этот регистр адреса последующих указателей. Таким образом, обслуживание всех асинхронных очередей выполняется по кругу, без привязки к конкретным кадрам. Контроллер останавливает обход асинхронного списка, когда обнаруживает опустошение всех его очередей, для возобновления обхода требуется вмешательство драйвера. Нормальной дисциплиной обслуживания очередей является отработка одной шинной транзакции из очереди, после чего контроллер переходит к следующей очереди. Возможен и специальный режим парковки (Asynchronous Schedule Park Mode), в котором контроллеру разрешается выполнять подряд по несколько транзакций из одной очереди. Режим парковки распространяется на все очереди высокоскоростных асинхронных передач.

Дескриптор iTD описывает изохронную передачу, которая может выполняться за1–8 этапов (микрокадров, в которых происходит обращение к данному дескриптору). Каждому этапу в дескрипторе соответствует своя запись (transaction record), управляющая выполнением и отражающая состояние транзакции (активность, ошибки выполнения, необходимость прерывания по выполнению, реальная длина) и содержащая указатель на буфер данных. Каждый этап может выполняться за 1–3 транзакции в микрокадре (точка может быть широкополосной). Дескриптор содержит и описание конечной точки: адрес устройства и точки, направление, размер пакета. Контроллер формирует транзакции исходя из указанного размера пакета. Буферы для данных могут располагаться в разных физических страницах памяти, но логически они должны представлять собой непрерывную область в виртуальной памяти. Для хранения данных (максимум 8 этапов по три транзакции по 1024 байт — 24 576 байт) может потребоваться до 7 страниц по 4 кбайт; для всех этих страниц в дескрипторе имеются соответствующие указатели.

Дескриптор siTD описывает одну расщепленную транзакцию. Адресная часть содержит номер и направление конечной точки, адрес устройства, а также адрес и номер порта хаба, выполняющего трансляцию данной транзакции. В дескрипторе имеются поля битовых масок μFrame_S-mask и μFrame_C-mask, определяющих, в каких микрокадрах данного кадра должны выполняться транзакции SS и CS соответственно. Контроллер в дескрипторе отмечает микрокадры, в которых в действительности происходили транзакции CS. Дескриптор имеет обычный набор полей, управляющих выполнением и отражающих состояние транзакции (активность, ошибки выполнения, необходимость прерывания по выполнению, реальная длина). Кроме того, в siTD имеются специфические поля, управляющие текущей фазой (SS или CS), а также признак специфической ошибки расщепленной транзакции — пропуска микрокадра, в котором должна выполняться очередная транзакция CS. Этот пропуск может случиться, если контроллер не выпустит текущую транзакцию из-за нехватки времени в микрокадре. Блок передаваемых данных (до 1023 байт) может располагаться в одной или двух физических страницах памяти, и в дескрипторе для них имеются необходимые указатели. В siTD имеется специфический элемент — обратный указатель (Back Pointer) на siTD предыдущего кадра, который используется при планировании транзакций IN, завершающихся близко к границе кадра.

Элемент очереди-дескриптор передачи qTD, описывает одну передачу размером до 20 480 байт. Дескриптор привязан к своему заголовку очереди (QH); он содержит пару указателей на следующие элементы данной очереди:

• основной, указывающий на дескриптор следующей передачи, которую требуется выполнить после нормального завершения текущей;
• альтернативный, указывающий на дескриптор передачи, которую требуется выполнить в случае завершения текущей передачи по приему короткого пакета

Дескриптор имеет обычный набор полей, управляющих выполнением и отражающих состояние транзакции: активность, ошибки выполнения, необходимость прерывания по выполнению, используемый маркер (IN, OUT или SETUP). В дескрипторе указывается общая длина передачи. Буфер данных для передачи должен располагаться в непрерывной области виртуальной памяти; для описания буфера передачи максимальной длины имеется массив из пяти указателей физических страниц.

Заголовок очереди QH создается для каждой сконфигурированной неизохронной конечной точки каждого устройства USB. Заголовки очередей непериодических конечных точек связаны между собой по горизонтали в кольцо, для чего в каждом заголовке имеется соответствующий указатель. Заголовок очереди несет исчерпывающее описание конечной точки: номер и направление точки, максимальный размер пакета, число пакетов в микрокадре (для широкополосных точек), адрес устройства, его скорость. Для FS/LS устройств имеется и информация для выполнения расщепленных транзакций: номер хаба и порта, выполняющего расщепление транзакций, маски микрокадров для транзакций SS и CS. В заголовке очереди имеется оверлейная область, в которую контроллер помещает необходимые ему поля qTD текущей транзакции. Продвижение по очереди осуществляет контроллер, помещая в оверлей следующий qTD после завершения отработки предыдущего.

Контроллер EHC вырабатывает прерывания для разных категорий событий, и категории могут быть селективно замаскированы:

• по завершении передачи, в дескрипторе которой имеется соответствующий признак, а также по приему короткого пакета. Эти прерывания могут быть задержаны по времени до определенного задаваемого программно порога, что позволяет снизить частоту запросов прерывания от EHC. Без задержки частота запросов может достигать частоты микрокадров (для IBM PC это слишком часто); с задержкой они не смогут появляться быстрее, чем определяет значение порога;
• по событию хост-контроллера: оборот по списку кадров, изменению состояния или перегрузке портов хаба, специальному разрешению программного изменения последовательности заголовков очередей, по ошибке системного подключения (переполнение или переопустошение буфера FIFO из-за занятости шины PCI).

Постановка запросов передач в очереди, как и включение изохронных передач в план, а также добавление/удаление очередей может выполняться драйвером динамически, во время работы хост-контроллера. Однако для сохранения целостности и связанности структур программа должна соблюдать определенные правила взаимодействия, чтобы не пытаться изменять структуры, которые в данный момент отрабатываются контроллером. Для этой синхронизации хост-контроллер использует специальные биты-признаки в своем регистре состояния и в структурах данных. Для «сбора урожая» — поиска отработанных передач — драйверу приходится просматривать во всех дескрипторах передач признаки активности. Такого сервиса, как очередь исполненных передач (как в OHC), контроллер EHC не предоставляет. Но по сравнению с UHC, конечно же, объем работ драйвера EHC сокращается, поскольку этот контроллер оперирует передачами, а не транзакциями. Однако у драйвера EHC появляется дополнительная довольно сложная задача — планирование расщепленных транзакций.