IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)

Статья
08/07/2023

IOCTL_MIPI_DSI_TRANSMISSION отправляется для отправки последовательности пакетов MIPI DSI на периферийное устройство.

Основной код

IRP_MJ_DEVICE_CONTROL

Входной буфер

Недоступно

Длина входного буфера

Недоступно

Выходной буфер

Недоступно

Длина выходного буфера

Недоступно

Буфер входных и выходных данных

Структура DXGK_DSI_TRANSMISSION , за которой следуют DXGK_DSI_PACKET структуры, содержащие пакеты.

Длина входного/выходного буфера

По крайней мере sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload. Дополнительные сведения см. в разделе "Примечания".

Блок состояния

Irp->IoStatus.Status имеет значение STATUS_SUCCESS, если запрос выполнен успешно. В противном случае для параметра Состояние устанавливается соответствующее условие ошибки в виде кода NTSTATUS. Дополнительные сведения см. в разделе Значения NTSTATUS.

Драйверы портов и минипортов мониторов, изготовителей оборудования и портов отображения должны обрабатывать ICTLs интерфейса цифрового последовательного интерфейса (DSI) для мобильных отраслевых процессоров (MIPI).

Выполнение передач

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

Каждый запрос на передачу состоит из одного буфера, который заполняется драйвером панели OEM, передается в стек монитора и возвращается с результатами передачи, если таковые есть. Буфер содержит общие сведения о передаче с полями ввода и вывода, за которыми следует массив DXGK_DSI_PACKET структур переменной величины. Пакеты описываются в терминах DSI, так что любой пакет DSI может быть описан, однако ОС будет анализировать пакеты и отклонять любую передачу, которая включает запрещенные пакеты. Все пакеты, кроме последнего, по определению DSI, записывают пакеты, которые могут быть либо короткими( в этом случае буфер полезных данных не используется), либо длинными, которые помещаются в буфер полезных данных . Последнему пакету в передаче, который может быть чтением или записью, разрешено использовать расширенные полезные данные, выделяя и описывая больший буфер, который позволит свободное место для операций чтения или записи любого размера, вплоть до ограничения DSI длинных пакетов данных в 64K-1 байт данных. Это позволяет помещать в очередь драйверу последовательность небольших пакетов записи в одном вызове, но требует, чтобы большие пакеты отправлялись по отдельности. Значение поля FinalPacketExtraPayload указывает, сколько дополнительных байтов было выделено, но это также необходимо учитывать в поле TotalBufferSize .

Драйвер панели OEM отвечает за обеспечение того, чтобы запрашиваемые передачи не конфликтовли и не влияли на другие передачи, которые графический драйвер использует для нормального взаимодействия с панелью из-за чрезмерных запросов или выполнения запросов, которые могут привести к задержкам при обработке других передач. Драйвер панели не должен изменять состояние, которое может привести к последующим сбоям в графическом драйвере, например изменение времени панели с помощью команд MCS. Аналогичным образом, если ОС запросила изменение дисплея через графический драйвер, например увеличение яркости, драйвер панели не должен использовать команды DSI для отмены этого изменения в ответ или в других целях.

IOCTL_MIPI_DSI_TRANSMISSION используется для запроса передачи на периферийное устройство, содержащее один или несколько пакетов DSI. Драйвер панели всегда должен инициализировать TotalBufferSize, PacketCount и первые три БАЙТа каждого пакета. Драйвер панели может переопределить поведение по умолчанию с помощью ненулевых значений для TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode и FinalCommandExtraPayload. Все неинициализированные значения должны иметь нулевое значение.

ОПЕРАЦИОННая система гарантирует, что последовательность пакетов DSI имеет правильный формат, с допустимыми сведениями во всех определенных полях и правильными размерами буфера. Операционная система отвечает за инициализацию поля FailedPacket для DXGK_DSI_INVALID_PACKET_INDEX поэтому дальнейшая проверка в ОС или драйвере должна задаваться только в том случае, если обнаружена проблема с определенным пакетом. Если структура DXGK_DSI_TRANSMISSION имеет неправильный формат, ОС установит флаг DXGK_HOST_DSI_INVALID_TRANSMISSION в поле HostErrors, чтобы отличить его от других ошибок недопустимых параметров.

Чтобы считаться правильно сформированным, все должно быть верным:

TotalBufferSize >= sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload
FinalPacketExtraPayload <= 64K-1-DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE (0xFFF7)
TotalBufferSize <= ROUND_TO_PAGES( sizeof(DXGK_DSI_TRANSMISSION) + (0xFE * sizeof(DXGK_DSI_PACKET)) + 0xFFF7 )
PacketCount != 0
Только последний пакет может быть прочитан
Только последний длинный пакет записи может иметь значение LongWriteWordCount больше DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE

Проверка пакетов

Хотя ОПЕРАЦИОННая система не попытается полностью проверить содержимое всех пакетов, она отклоняет передачу, содержащую команды DSI, отличные от следующих, и завершает IOCTL без вызова графического драйвера:

Значение типа данных	Описание
0x03	Общая короткая запись, без параметров
0x13	Общая короткая запись, 1 параметр
0x23	Общая короткая запись, 2 параметра
0x04	Универсальный read, без параметров
0x14	Универсальный параметр READ, 1 параметр
0x24	Универсальный read, 2 параметра
0x05	DCS Short WRITE, без параметров
0x15	DCS Short WRITE, 1 параметр
0x06	DCS READ, без параметров
0x29	Общая длинная запись
0x39	Долгое запись и write_LUT DCS

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

Для DCS UCS неопределенные команды не должны использоваться графическим драйвером, поэтому ОС позволит использовать их драйверу панели, хотя явно существует риск того, что будущие изменения спецификации MIPI-DCS определяют команду, поэтому команды MCS предпочтительнее.

Стандартизированные команды DCS UCS будут использоваться графическим драйвером во время нормальной работы и потенциально могут использоваться драйвером панели, поэтому необходимо снизить риск команд, отправленных драйвером панели OEM, которые вызывают проблемы с последующими командами графического драйвера. Для этого ОС будет анализировать команды DCS и отклонять пакеты, которые, как ожидается, вызовут конфликты, если драйвер панели изготовителя оборудования не установит ManufacturingMode флаг и ОС не подтвердит, что система находится в производственном режиме. Если флаг установлен, но система не находится в производственном режиме, IOCTL передачи будет завершен с флагом DXGK_HOST_DSI_INVALID_TRANSMISSION , установленным в HostErrors поле без вызова графического драйвера.

Условия, для которых требуется полностью определенная транзакция вместо использования передачи, будут следующими:

Время простоя требуется до или после, например DCS soft_reset
Изменение операционной среды для вывода кадров, например dcs set_vsync_timing и enter_sleep_mode
Использование транзакций с семантикой запуска и продолжения, где графическому драйверу также может потребоваться доступ к тем же данным, например DCS write_memory_start/write_memory_continue

Кроме того, существуют классы команд DCS, которые будут отклонены ОС при отправке в виде передачи:

Любая команда, которая должна быть полностью определена, как описано выше
Считывает пиксельные данные, которые можно использовать для выскабливания экрана
Запись пиксельных данных

Команды UCS, которые ос будет передавать в графический драйвер

Hex	Get-Help
00h	Nop
26 ч.	set_gamma_curve
2Dh	write_LUT
51 ч	set_display_brightness
52 ч	get_display_brightness
53h	write_control_display
54h	get_control_display
55h	write_power_save
56h	get_power_save
5Eh	set_CABC_min_brightness
5Fh	get_CABC_min_brightness
03h	get_compression_mode
05h	get_error_count_on_DSI
06h	get_red_channel
07h	get_green_channel
08h	get_blue_channel
0Ah	get_power_mode
0Bh	get_address_mode
0Ch	get_pixel_format
0Dh	get_display_mode
0Eh	get_signal_mode
0Fh	get_diagnostic_result
14 ч	get_image_checksum_rgb
15 ч	get_image_checksum_ct
3Fh	get_3D_control
45 ч	get_scanline

Команды UCS, которые ос будет отклонять

Hex	Get-Help
01h	soft_reset . Обратите внимание, что это должно быть отправлено через IOCTL_MIPI_DSI_RESET
10 ч	enter_sleep_mode
11ч	exit_sleep_mode
12 ч	enter_partial_mode
13 ч.	enter_normal_mode
20 ч	exit_invert_mode
21 ч.	enter_invert_mode
28 ч	set_display_off
29h	set_display_on
2Ah	set_column_address
2Bh	set_page_address
2Ch	write_memory_start
2Eh	read_memory_start
30 ч	set_partial_rows
31h	set_partial_columns
33 ч	set_scroll_area
34 ч	set_tear_off
35 ч	set_tear_on
36h	set_address_mode
37h	set_scroll_start
38h	exit_idle_mode
39h	enter_idle_mode
3Ah	set_pixel_format
3Ch	write_memory_continue
3Dh	set_3D_control
3Eh	read_memory_continue
40 ч	set_vsync_timing
44 ч	set_tear_scanline
A1h	read_DDB_start
A2h	read_PPS_start
A8h	read_DDB_continue
A9h	read_PPS_continue

Примечание

Политики проверки ОС могут быть изменены в будущих выпусках.

Реализация графического драйвера

Если передача проходит проверку ОС, ОС передает буфер графическому драйверу с помощью DsiTransmission.

Добавление передач oem в интерфейс, который уже используется для отправки пиксельных и управляющих данных на основе запросов ОС и потребностей периферийного управления, неизбежно означает, что графическому драйверу потребуется улучшить внутреннюю последовательность, чтобы обеспечить правильное включение этого дополнительного потока пакетов. Графический драйвер не должен изменять порядок пакетов в рамках передачи от драйвера панели OEM и должен отправлять всю последовательность непрерывно и без чередование других пакетов. Графический драйвер не обязан поддерживать порядок собственных пакетов относительно времени поступления запроса на передачу панели OEM, поэтому может выбрать отправку пакетов для настройки следующего кадра до (или после) отправки передачи панели OEM. Если завершение запущенной передачи на панели OEM может привести к пропуску временного окна критическими пакетами, драйвер должен сообщить о том, что передача отменена. Если передача не запущена, но драйвер ожидает, что критически важные пакеты пропустят временное окно, драйвер должен отложить запуск передачи до следующего периода пробела. Если отсрочка передачи панели OEM приведет к тому, что она ждала запуска более двух кадров, драйвер должен сообщить о передаче как упавшей.

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

Если графический драйвер отклоняет передачу из-за проблемы с пакетом, он должен обновить FailedPacket поле с индексом первого пакета, что приводит к отклонению передачи, и установить HostErrors флаг DXGK_HOST_DSI_DRIVER_REJECTED_PACKET перед возвратом. Если указано переопределение режима передачи, драйвер должен убедиться, что переопределение совместимо с аппаратными ограничениями, и в противном случае установите HostErrors флаг DXGK_HOST_DSI_BAD_TRANSMISSION_MODE перед возвратом.

Если во время обмена данными происходит сбой, графический драйвер должен обновить FailedPacket поле с индексом пакета, который завершился сбоем, однако во всех случаях драйвер может не определить пакет, поэтому драйвер должен оставить значение по умолчанию, DXGK_DSI_INVALID_PACKET_INDEX, в таких случаях.

Графический драйвер отвечает за обмен пакетами, поэтому должен гарантировать, что все суммы проверка вычисляются и проверяются. Любая передача, которая заканчивается чтением, будет коротким пакетом, поэтому поля Data0 и Data1 содержат любые параметры, а ответ может быть коротким или длинным пакетом. Графический драйвер может не знать, в какой форме и как долго будут возвращены данные, но максимальный размер — это полный размер полезных данных для окончательного пакета, включая FinalPacketExtraPayload. ОПЕРАЦИОННая система проверяет, что это значение не превышает TargetMaximumReturnPacketSize значение, указанное драйвером в его возможностях для целевого объекта, но драйвер должен убедиться, что этот буфер не будет переполнен периферийным устройством, сообщающим больше данных, и что данные из периферийного устройства не усечены из-за того, что размер параметра MaximumReturnPacketSize в настоящее время применяется к периферийной системе. Драйвер записывает число байтов, считанных в буфер, в ReadWordCount поле, описывающее передачу.

В некоторых случаях графический драйвер принудительно сбрасывает либо интерфейс связи на панель, либо на всю панель из-за ошибок, которые могут не быть связаны с драйвером панели изготовителя оборудования. Чтобы решить эту проблему, драйвер должен сообщить о DXGK_HOST_DSI_INTERFACE_RESET или DXGK_HOST_DSI_DEVICE_RESET, заданных в HostErrors поле при первой попытке передачи передачи после сброса, чтобы драйвер панели OEM смог обнаружить ситуацию и восстановиться. Драйвер не должен отправлять эту передачу на оборудование, но драйвер панели OEM может просто повторить ту же команду, если восстановление не требуется. В этом случае драйвер должен продолжить обработку передачи обычным образом.

Завершение передачи

После завершения FailedPacketIOCTL полезные данные , ReadWordCount, MipiErrorsHostErrors и для прочитанного (окончательного) пакета могли быть обновлены в зависимости от результата. Если при обработке передачи обнаружены ошибки, драйвер панели изготовителя оборудования должен использовать выходные MipiErrors значения и HostErrors , чтобы определить, как восстановить и продолжить.

Чтобы обеспечить возврат выходных данных вызывающей объекту для предоставления сведений о любых ошибках, вызовы IOCTL и DDI должны сообщать об успешном выполнении, даже если ошибки обнаружены. Успешное выполнение не означает, что транзакция прошла успешно, а указывает на то, что вызовы для обработки транзакции продолжались должным образом, и при необходимости были установлены флаги ошибок. Сбои могут по-прежнему сообщаться для таких условий, как неподдерживаемый вызов DDI (предположительно из-за несоответствия драйвера), сбои выделения памяти или передача полностью недопустимых параметров, например передача буфера NULL. Если при успешном вызове не сообщается об ошибках, вызывающий объект должен предположить, что транзакция прошла успешно.