IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)

Artículo
08/07/2023

Código principal: IRP_MJ_DEVICE_CONTROL

IOCTL_MIPI_DSI_TRANSMISSION se emite para enviar una secuencia de paquetes DSI de MIPI a un periférico.

Código principal

IRP_MJ_DEVICE_CONTROL

Búfer de entrada

N/D

Longitud del búfer de entrada

N/D

Búfer de salida

N/D

Longitud del búfer de salida

N/D

Búfer de entrada y salida

Estructura DXGK_DSI_TRANSMISSION seguida de estructuras DXGK_DSI_PACKET que contienen los paquetes.

Longitud del búfer de entrada y salida

Al menos sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload. Para obtener información detallada, vea la sección Comentarios de.

Bloque de estado

Irp->IoStatus.Status se establece en STATUS_SUCCESS si la solicitud se realiza correctamente. De lo contrario, Status se establece en la condición de error adecuada como código NTSTATUS. Para obtener más información, vea Valores NTSTATUS.

Comentarios

Los controladores de puerto/minipuerto de supervisión, panel oem y display deben controlar las ICTLs de interfaz de procesador del sector móvil (MIPI) Digital Serial Interface(DSI).

Realización de transmisiones

Para permitir que un controlador de panel interactúe sobre esta interfaz privada de otro modo entre el adaptador de gráficos y el hardware del panel, las transacciones no deben tener ningún efecto de controlador gráfico, excepto el tiempo que ocupa el bus o deben definirse completamente para que el controlador de gráficos esté en control. Dado que el punto de permitir que un controlador de panel interactúe es proporcionar compatibilidad con características de panel personalizadas que son opacas para el controlador de gráficos, las operaciones totalmente definidas están pensadas para restringirse a las transacciones en las que el controlador del panel necesita realizar una operación estandarizada que no se puede realizar sin la participación del controlador gráfico. Estas transacciones se tratarán como excepciones enrutadas explícitamente en lugar de como transmisiones.

Cada solicitud de transmisión consta de un único búfer que el controlador del panel OEM rellena, pasa la pila del monitor y se devuelve con los resultados de la transmisión, si existe. El búfer contiene información general sobre la transmisión, con campos de entrada y salida, seguidos de una matriz de tamaño variable de DXGK_DSI_PACKET estructuras. Los paquetes se describen en términos DSI, de modo que se pueda describir cualquier paquete DSI, pero el sistema operativo analizará los paquetes y rechazará cualquier transmisión que incluya paquetes no permitidos. Todos los paquetes excepto los últimos son, por definición de DSI, escriben paquetes que pueden ser escrituras cortas, en cuyo caso el búfer de carga no se usa o escrituras largas que caben en el búfer de carga . El último paquete de una transmisión, que puede ser de lectura o escritura, puede usar una carga extendida mediante la asignación y descripción de un búfer mayor que permitirá espacio para lecturas o escrituras de cualquier tamaño hasta el límite de datos de paquetes largos DSI de 64K-1 bytes de datos. Esto permite que las secuencias de paquetes de escritura pequeños se ponen en cola en el controlador en una sola llamada, pero requiere que los paquetes más grandes se envíen individualmente. El valor del campo FinalPacketExtraPayload indica cuántos bytes adicionales se han asignado, pero también se debe tener en cuenta en el campo TotalBufferSize .

El controlador del panel OEM es responsable de garantizar que las transmisiones que solicita no entren en conflicto o interfieran con otras transmisiones que el controlador gráfico utiliza para la interacción normal con el panel debido a solicitudes excesivas o operaciones de solicitud que provocarían retrasos en el procesamiento de otras transmisiones. El controlador del panel no debe cambiar ningún estado que cause errores posteriores en el controlador de gráficos, por ejemplo, cambiar el tiempo del panel a través de comandos MCS. Del mismo modo, si el sistema operativo ha solicitado un cambio de pantalla, a través del controlador de gráficos, por ejemplo, un aumento del brillo, el controlador del panel no debe usar comandos DSI para deshacer ese cambio, ya sea en respuesta o con otros fines.

IOCTL_MIPI_DSI_TRANSMISSION se usa para solicitar una transmisión al periférico que contiene uno o varios paquetes DSI. El controlador del panel siempre debe inicializar TotalBufferSize, PacketCount y los tres primeros BYTES de cada paquete. El controlador del panel puede invalidar el comportamiento predeterminado con valores distintos de cero para TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode y FinalCommandExtraPayload. Todos los valores sin inicializar deben establecerse en cero.

El sistema operativo garantizará que la secuencia de paquetes DSI esté bien formada, con información válida en todos los campos definidos y tamaños de búfer correctos. El sistema operativo es responsable de inicializar el campo FailedPacket en DXGK_DSI_INVALID_PACKET_INDEX para que la validación adicional en el sistema operativo o el controlador solo necesite establecer el campo si se encuentra un problema con un paquete determinado. Si la estructura de DXGK_DSI_TRANSMISSION no tiene el formato correcto, el sistema operativo establecerá la marca DXGK_HOST_DSI_INVALID_TRANSMISSION en el campo HostErrors para distinguirlo de otros errores de parámetros no válidos.

Para considerarse bien formado, todo lo siguiente debe ser true:

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
Solo se permite que el último paquete sea una lectura.
Solo un paquete de escritura larga final puede tener un valor LongWriteWordCount mayor que DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE

Validación de paquetes

Aunque el sistema operativo no intentará validar completamente el contenido de todos los paquetes, rechazará una transmisión que contenga comandos DSI distintos de los siguientes, completando el IOCTL sin llamar al controlador de gráficos:

Valor de tipo de datos	Descripción
0x03	Escritura corta genérica, sin parámetros
0x13	Generic Short WRITE, 1 parámetro
0x23	Generic Short WRITE, 2 parámetros
0x04	LECTURA genérica, sin parámetros
0x14	Read genérico, 1 parámetro
0x24	Lectura genérica, 2 parámetros
0x05	DCS Short WRITE, sin parámetros
0x15	DCS Short WRITE, 1 parámetro
0x06	DCS READ, sin parámetros
0x29	Escritura larga genérica
0x39	Escritura y write_LUT largos de DCS

Los comandos genéricos de lectura y escritura requieren comprender la especificación del panel, por lo que la expectativa es que el controlador del panel pueda usar libremente estos comandos sin causar problemas para el controlador de gráficos siempre y cuando el bus no se use excesivamente. Del mismo modo, los comandos DCS MCS se definen explícitamente para el uso del fabricante, por lo que no debe haber ningún problema con la interferencia entre el controlador gráfico y el controlador del panel.

En el caso de DCS UCS, no se espera que los comandos no definidos los use el controlador de gráficos, por lo que el sistema operativo les permitirá usarlos por el controlador del panel, aunque existe claramente un riesgo de que los cambios futuros en la especificación MIPI-DCS definan el comando, por lo que se prefieren los comandos MCS.

El controlador de gráficos usará los comandos DCS UCS estandarizados durante el funcionamiento normal y es posible que el controlador del panel pueda usarlos, por lo que es necesario mitigar el riesgo de comandos enviados por el controlador del panel OEM que provoca problemas con comandos de controladores gráficos posteriores. Para ello, el sistema operativo analizará los comandos dcS y rechazará los paquetes que se espera que causen conflictos a menos que el controlador del panel OEM establezca la ManufacturingMode marca y el sistema operativo confirme que el sistema está en modo de fabricación. Si se establece la marca pero el sistema no está en modo de fabricación, el IOCTL de transmisión se completará con la marca DXGK_HOST_DSI_INVALID_TRANSMISSION establecida en el HostErrors campo sin llamar al controlador de gráficos.

Las condiciones que requerirían una transacción totalmente definida en lugar de usar una transmisión serían las siguientes:

Se requieren períodos de inactividad con tiempo de inactividad antes o después, como DCS soft_reset
Cambio del entorno operativo para la salida de fotogramas, como dcs set_vsync_timing y enter_sleep_mode
Uso de transacciones con semántica de inicio/continuación, donde el controlador de gráficos también puede necesitar acceder a los mismos datos, como DCS write_memory_start/write_memory_continue

Además, hay clases de comandos dcS que el sistema operativo rechazará cuando se envíe como transmisión:

Cualquier comando que deba definirse por completo, como se ha descrito anteriormente.
Lecturas de datos de píxeles que se podrían usar para la extracción de pantalla
Escrituras de datos de píxeles

Comandos UCS que el sistema operativo pasará al controlador de gráficos

Hex	Get-Help
00 h	Nop
26h	set_gamma_curve
2Dh	write_LUT
51h	set_display_brightness
52h	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
14h	get_image_checksum_rgb
15h	get_image_checksum_ct
3Fh	get_3D_control
45h	get_scanline

Comandos UCS que rechazará el sistema operativo

Hex	Get-Help
01h	soft_reset: tenga en cuenta que debe enviarse a través de un IOCTL_MIPI_DSI_RESET
10h	enter_sleep_mode
11h	exit_sleep_mode
12h	enter_partial_mode
13h	enter_normal_mode
20h	exit_invert_mode
21h	enter_invert_mode
28h	set_display_off
29h	set_display_on
2Ah	set_column_address
2Bh	set_page_address
2Ch	write_memory_start
2Eh	read_memory_start
30h	set_partial_rows
31h	set_partial_columns
33h	set_scroll_area
34h	set_tear_off
35h	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
40h	set_vsync_timing
44h	set_tear_scanline
A1h	read_DDB_start
A2h	read_PPS_start
A8h	read_DDB_continue
A9h	read_PPS_continue

Nota

Las directivas de validación del sistema operativo se pueden modificar en futuras versiones.

Implementación del controlador de gráficos

Si la transmisión pasa la validación del sistema operativo, el sistema operativo pasa el búfer al controlador de gráficos mediante DsiTransmission.

Agregar transmisiones OEM a una interfaz que ya se usa para enviar datos de píxeles y de control basados en solicitudes del sistema operativo y las necesidades de control periférico, inevitablemente significa que el controlador de gráficos tendrá que mejorar su secuencia interna para asegurarse de que esta secuencia adicional de paquetes se puede incorporar correctamente. El controlador de gráficos no debe reordenar paquetes dentro de una transmisión desde el controlador del panel OEM y debe enviar toda la secuencia sin interrupciones y sin intercalar otros paquetes. El controlador de gráficos no es necesario para mantener el orden de sus propios paquetes con respecto a la hora de llegada de la solicitud de transmisión del panel OEM, por lo que puede optar por enviar paquetes para configurar el siguiente marco antes (o después) enviando una transmisión de panel OEM. Si la finalización de una transmisión iniciada del panel OEM amenaza con provocar que los paquetes críticos pierdan su período de tiempo, el controlador debe notificar la transmisión como cancelada. Si una transmisión no se ha iniciado, pero el controlador espera que se pierda el período de tiempo de los paquetes críticos, el controlador debe aplazar el inicio de la transmisión hasta el siguiente período de espacio en blanco. Si aplazar una transmisión de panel OEM provocaría que hubiera estado esperando que se iniciaran más de dos fotogramas, el controlador debe informar de la transmisión como descartada.

No es posible que un controlador gráfico garantice que las transmisiones que envía en nombre del controlador del panel no entren en conflicto con las transmisiones sobre las que tiene control. El controlador puede optar por inspeccionar paquetes dentro de una transmisión y rechazar la transmisión si causarían problemas, pero los paquetes que se consideran no seguros deben marcarse para el rechazo del nivel del sistema operativo, por lo que el rechazo del nivel de controlador debería deberse idealmente a problemas específicos del proveedor de gráficos. El controlador no debe intentar almacenar en caché ni optimizar las lecturas o escrituras, incluso si los paquetes parecen ser comandos estandarizados.

Si el controlador de gráficos rechaza una transmisión debido a un problema con un paquete, debe actualizar el FailedPacket campo con el índice del primer paquete que hace que se rechace la transmisión y establezca la HostErrors marca DXGK_HOST_DSI_DRIVER_REJECTED_PACKET antes de devolver. Si se proporciona una invalidación del modo de transmisión, el controlador debe comprobar que la invalidación es compatible con sus restricciones de hardware y, si no es así, establezca la HostErrors marca de DXGK_HOST_DSI_BAD_TRANSMISSION_MODE antes de devolverla.

Si se produce un error durante la comunicación, el controlador de gráficos debe actualizar el FailedPacket campo con el índice del paquete que produjo un error, pero puede que no sea posible en todos los casos para que el controlador identifique el paquete para que el controlador deba dejar el valor predeterminado, DXGK_DSI_INVALID_PACKET_INDEX, para estos casos.

El controlador de gráficos es responsable de la comunicación de los paquetes, por lo que debe asegurarse de que las sumas de comprobación se calculan y comprueban. Cualquier transmisión que termine con una lectura será un paquete corto, por lo que los campos Data0 y Data1 contienen cualquier parámetro y la respuesta puede ser un paquete corto o largo. Es posible que el controlador de gráficos no sepa qué formulario y cuánto tiempo serán los datos devueltos, pero el tamaño máximo es el tamaño completo de la carga del paquete final, incluido .FinalPacketExtraPayload El sistema operativo validará que este valor no es mayor que el TargetMaximumReturnPacketSize notificado por el controlador en sus funcionalidades para el destino, pero el controlador debe asegurarse de que este búfer no se supere mediante un informe periférico de más datos y que los datos del periférico no se truncan debido a que maximumReturnPacketSize se aplica actualmente al periférico. El controlador escribe el número de bytes leídos en el búfer en el ReadWordCount campo que describe la transmisión.

Puede haber casos en los que el controlador de gráficos se ve obligado a restablecer la interfaz de comunicaciones en el panel, o todo el panel debido a errores que pueden no estar relacionados con y puede que no sean observables para el controlador del panel OEM. Para tratar esto, el controlador debe notificar DXGK_HOST_DSI_INTERFACE_RESET o DXGK_HOST_DSI_DEVICE_RESET establecido en el HostErrors campo en el primer intento de transmisión después del restablecimiento para que el controlador del panel OEM pueda detectar la situación y recuperarse. El controlador no debe enviar esta transmisión al hardware, pero el controlador del panel OEM puede simplemente reintentar el mismo comando si no se requiere recuperación, en cuyo caso el controlador debe continuar con el procesamiento de la transmisión como de costumbre.

Completar una transmisión

Cuando el IOCTL completa la FailedPacketcarga de , ReadWordCount, HostErrorsMipiErrorsy para un paquete de lectura (final) se puede haber actualizado en función del resultado. Si se encontraron errores durante el procesamiento de la transmisión, el controlador del panel OEM debe usar los MipiErrors valores de salida y HostErrors para determinar cómo recuperar y continuar.

Para asegurarse de que la salida se devuelve al autor de la llamada para proporcionar detalles de los errores, las llamadas IOCTL y DDI deben informar de que se ha realizado correctamente, incluso si se encuentran errores. Correcto no indica que la transacción se realizó correctamente, indica que las llamadas a para controlar la transacción se continuaron según lo previsto y se han establecido marcas de error, si procede. Es posible que todavía se notifiquen errores para condiciones como una llamada DDI no admitida (probablemente debido a un error de coincidencia del controlador), errores de asignación de memoria o pasar parámetros completamente incorrectos, como pasar un búfer NULL. Si no se notifica ningún error para una llamada correcta, el autor de la llamada debe suponer que la transacción se realizó correctamente.