IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)

Article
08/07/2023

Code principal : IRP_MJ_DEVICE_CONTROL

IOCTL_MIPI_DSI_TRANSMISSION est émis pour envoyer une séquence de paquets DSI MIPI à un périphérique.

Code principal

IRP_MJ_DEVICE_CONTROL

Mémoire tampon d'entrée

n/a

Longueur de la mémoire tampon d’entrée

n/a

Mémoire tampon de sortie

n/a

Longueur de la mémoire tampon de sortie

n/a

Mémoire tampon d’entrée/sortie

Structure DXGK_DSI_TRANSMISSION suivie de DXGK_DSI_PACKET structures contenant les paquets.

Longueur de la mémoire tampon d’entrée/sortie

Au moins sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload. Pour plus de détails, consultez la section Notes.

Bloc d’état

Irp->IoStatus.Status est défini sur STATUS_SUCCESS si la demande réussit. Sinon, Status est défini sur la condition d’erreur appropriée en tant que code NTSTATUS. Pour plus d’informations, consultez Valeurs NTSTATUS.

Remarques

Le moniteur, le panneau oem et les pilotes de port/miniport d’affichage doivent gérer les IOCTL MIPI (Digital Serial Interface) DSI (Mobile Industry Interface).

Exécution de transmissions

Pour permettre à un pilote de panneau d’interagir sur cette interface privée par ailleurs entre la carte graphique et le matériel du panneau, les transactions doivent soit avoir aucun effet de pilote graphique, autre que le temps d’occupation du bus, soit être entièrement définies pour que le pilote graphique soit en contrôle. Étant donné que le but d’autoriser un pilote de panneau à interagir est de fournir une prise en charge des fonctionnalités de panneau personnalisées qui sont opaques pour le pilote graphique, les opérations entièrement définies sont destinées à être limitées aux transactions où le pilote de panneau doit effectuer une opération standardisée qui ne peut pas être effectuée sans l’intervention du pilote graphique. Ces transactions seront traitées comme des exceptions routées explicitement plutôt que comme des transmissions.

Chaque demande de transmission se compose d’une mémoire tampon unique qui est remplie par le pilote du panneau OEM, transmise à la pile du moniteur et retournée avec les résultats de la transmission, le cas échéant. La mémoire tampon contient des informations globales sur la transmission, avec des champs d’entrée et de sortie, suivis d’un tableau de taille variable de structures DXGK_DSI_PACKET . Les paquets sont décrits en termes DSI, de sorte que tout paquet DSI peut être décrit, mais le système d’exploitation analyse les paquets et rejette toute transmission qui inclut des paquets non autorisés. Tous les paquets à l’exception du dernier sont, par définition DSI, des paquets d’écriture qui peuvent être des écritures courtes, auquel cas la mémoire tampon de charge utile n’est pas utilisée, ou des écritures longues qui tiennent dans la mémoire tampon de charge utile . Le dernier paquet d’une transmission, qui peut être une lecture ou une écriture, est autorisé à utiliser une charge utile étendue en allouant et en décrivant une mémoire tampon plus grande qui permet d’espacer les lectures ou les écritures de toute taille jusqu’à la limite de données de paquets longs DSI de 64 Ko-1 octets de données. Cela permet de mettre en file d’attente des séquences de petits paquets d’écriture vers le pilote dans un seul appel, mais nécessite que les paquets plus volumineux soient envoyés individuellement. La valeur du champ FinalPacketExtraPayload indique le nombre d’octets supplémentaires qui ont été alloués, mais cela doit également être pris en compte dans le champ TotalBufferSize .

Le pilote de panneau OEM est chargé de s’assurer que les transmissions qu’il demande n’entrent pas en conflit ou n’interfèrent pas avec d’autres transmissions que le pilote graphique utilise pour une interaction normale avec le panneau en raison de demandes excessives ou de demandes d’opérations qui entraîneraient des retards dans le traitement d’autres transmissions. Le pilote de panneau ne doit pas modifier l’état qui entraînerait des défaillances ultérieures dans le pilote graphique, par exemple la modification du minutage du panneau via des commandes MCS. De même, si le système d’exploitation a demandé une modification d’affichage, via le pilote graphique, par exemple une augmentation de la luminosité, le pilote de panneau ne doit pas utiliser les commandes DSI pour annuler cette modification, que ce soit en réponse ou à d’autres fins.

IOCTL_MIPI_DSI_TRANSMISSION est utilisé pour demander une transmission au périphérique contenant un ou plusieurs paquets DSI. Le pilote de panneau doit toujours initialiser TotalBufferSize, PacketCount et les trois premiers octets de chaque paquet. Le pilote de panneau peut remplacer le comportement par défaut à l’aide de valeurs non nulles pour TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode et FinalCommandExtraPayload. Toutes les valeurs non initialisées doivent être définies sur zéro.

Le système d’exploitation s’assure que la séquence de paquets DSI est bien formée, avec des informations valides dans tous les champs définis et des tailles de mémoire tampon correctes. Le système d’exploitation est chargé d’initialiser le champ FailedPacket pour DXGK_DSI_INVALID_PACKET_INDEX de sorte qu’une validation supplémentaire dans le système d’exploitation ou le pilote ne doit définir le champ que si un problème est détecté avec un paquet particulier. Si la structure DXGK_DSI_TRANSMISSION n’est pas correctement formée, le système d’exploitation définit l’indicateur DXGK_HOST_DSI_INVALID_TRANSMISSION dans le champ HostErrors pour le distinguer des autres erreurs de paramètres non valides.

Pour être considérés comme bien formés, les éléments suivants doivent tous être vrais :

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
Seul le dernier paquet est autorisé à être lu
Seul un paquet d’écriture longue finale peut avoir une valeur LongWriteWordCount supérieure à DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE

Validation des paquets

Bien que le système d’exploitation ne tente pas de valider entièrement le contenu de tous les paquets, il rejette une transmission contenant des commandes DSI autres que les commandes suivantes, en effectuant l’IOCTL sans appeler le pilote graphique :

Valeur du type de données	Description
0x03	Écriture courte générique, aucun paramètre
0x13	Generic Short WRITE, 1 paramètre
0x23	Écriture courte générique, 2 paramètres
0x04	LECTURE générique, aucun paramètre
0x14	Read générique, paramètre 1
0x24	LECTURE générique, 2 paramètres
0x05	DCS Short WRITE, aucun paramètre
0x15	DCS Short WRITE, 1 paramètre
0x06	DCS READ, aucun paramètre
0x29	Écriture longue générique
0x39	Écriture/write_LUT longues DCS

Les commandes de lecture et d’écriture génériques nécessitent une compréhension de la spécification du panneau, de sorte que l’on s’attend à ce que ces commandes puissent être utilisées librement par le pilote de panneau sans causer de problèmes pour le pilote graphique tant que le bus n’est pas utilisé de manière excessive. De même, les commandes MCS DCS sont explicitement définies pour une utilisation par le fabricant. Il ne doit donc pas y avoir de problème d’interférence entre le pilote graphique et le pilote de panneau.

Pour DCS UCS, les commandes non définies ne sont pas censées être utilisées par le pilote graphique. Par conséquent, le système d’exploitation les autorisera à être utilisées par le pilote de panneau, bien qu’il existe clairement un risque que les futures modifications de spécification MIPI-DCS définissent la commande afin que les commandes MCS soient préférées.

Les commandes UCS DCS standardisées seront utilisées par le pilote graphique pendant un fonctionnement normal et sont potentiellement utilisables par le pilote de panneau, de sorte que le risque que les commandes envoyées par le pilote du panneau OEM provoquent des problèmes avec les commandes de pilotes graphiques suivantes doit être atténué. Pour ce faire, le système d’exploitation analyse les commandes DCS et rejette les paquets qui sont censés provoquer des conflits, sauf si le pilote du panneau OEM définit l’indicateur ManufacturingMode et que le système d’exploitation confirme que le système est en mode de fabrication. Si l’indicateur est défini mais que le système n’est pas en mode de fabrication, la transmission IOCTL est effectuée avec l’indicateur de DXGK_HOST_DSI_INVALID_TRANSMISSION défini dans le HostErrors champ sans appeler le pilote graphique.

Les conditions qui nécessiteraient une transaction entièrement définie au lieu d’utiliser une transmission seraient les suivantes :

Les périodes d’inactivité chrono timed sont requises avant ou après, telles que DCS soft_reset
Modification de l’environnement d’exploitation pour la sortie de trame, par exemple set_vsync_timing DCS et enter_sleep_mode
Utilisation de transactions avec une sémantique de démarrage/continue où le pilote graphique peut également avoir besoin d’accéder aux mêmes données, comme DCS write_memory_start/write_memory_continue

En outre, il existe des classes de commandes DCS qui seront rejetées par le système d’exploitation lorsqu’elles sont envoyées en tant que transmission :

Toute commande qui doit être entièrement définie, comme décrit ci-dessus
Lectures de données de pixels qui peuvent être utilisées pour le raclage d’écran
Écritures de données de pixels

Commandes UCS que le système d’exploitation transmettra au pilote graphique

Hex	Commande
00h	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

Commandes UCS que le système d’exploitation rejettera

Hex	Commande
01h	soft_reset : notez que cela doit être envoyé via 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

Notes

Les stratégies de validation du système d’exploitation peuvent être modifiées dans les versions ultérieures.

Implémentation du pilote graphics

Si la transmission réussit la validation du système d’exploitation, le système d’exploitation transmet la mémoire tampon au pilote graphique à l’aide de DsiTransmission.

L’ajout de transmissions OEM dans une interface qui est déjà utilisée pour envoyer des données de pixels et de contrôle en fonction des demandes du système d’exploitation et des besoins du contrôle périphérique signifie inévitablement que le pilote graphique devra améliorer son séquencement interne pour s’assurer que ce flux supplémentaire de paquets peut être incorporé correctement. Le pilote graphique ne doit pas réorganiser les paquets au sein d’une transmission à partir du pilote du panneau OEM et doit envoyer la séquence entière sans interruption et sans entrelacement d’autres paquets. Le pilote graphique n’est pas tenu de maintenir l’ordre de ses propres paquets par rapport à l’heure d’arrivée de la demande de transmission de panneau OEM. Il peut donc choisir d’envoyer des paquets pour configurer la trame suivante avant (ou après) l’envoi d’une transmission de panneau OEM. Si l’achèvement d’une transmission de panneau OEM démarrée menace d’entraîner l’absence de paquets critiques dans leur fenêtre de temps, le pilote doit signaler la transmission comme annulée. Si une transmission n’a pas démarré mais que le pilote s’attend à ce qu’elle entraîne l’absence de leur fenêtre de temps pour les paquets critiques, le pilote doit différer le démarrage de la transmission jusqu’à la prochaine période d’espacement. Si le report d’une transmission par panneau OEM entraînerait l’attente de plus de deux images pour démarrer, le pilote doit signaler la transmission comme étant abandonnée.

Il n’est pas possible pour un pilote graphique de s’assurer que les transmissions qu’il envoie pour le compte du pilote de panneau n’entrent pas en conflit avec les transmissions sur lesquelles il contrôle. Le pilote peut choisir d’inspecter les paquets au sein d’une transmission et de rejeter la transmission s’ils provoquent des problèmes, mais tous les paquets considérés comme non sécurisés doivent être marqués pour le rejet au niveau du système d’exploitation, de sorte que le rejet au niveau du pilote doit idéalement être dû à des préoccupations spécifiques du fournisseur de graphiques. Le pilote ne doit pas essayer de mettre en cache ou d’optimiser les lectures ou les écritures, même si les paquets semblent être des commandes standardisées.

Si le pilote graphique rejette une transmission en raison d’un problème avec un paquet, il doit mettre à jour le FailedPacket champ avec l’index du premier paquet, ce qui entraîne le rejet de la transmission et définir l’indicateur HostErrors DXGK_HOST_DSI_DRIVER_REJECTED_PACKET avant de revenir. Si un remplacement du mode de transmission est fourni, le pilote doit vérifier que le remplacement est compatible avec ses contraintes matérielles et, si ce n’est pas le cas, définir l’indicateur HostErrors DXGK_HOST_DSI_BAD_TRANSMISSION_MODE avant de revenir.

Si un échec se produit lors de la communication, le pilote graphique doit mettre à jour le FailedPacket champ avec l’index du paquet qui a échoué, mais il peut ne pas être possible dans tous les cas pour le pilote d’identifier le paquet de sorte que le pilote doit laisser la valeur par défaut, DXGK_DSI_INVALID_PACKET_INDEX, pour ce cas.

Le pilote graphique est responsable de la communication des paquets et doit donc s’assurer que les sommes case activée sont calculées et vérifiées. Toute transmission qui se termine par une lecture est un paquet court, de sorte que les champs Data0 et Data1 contiennent tous les paramètres et la réponse peut être un paquet court ou long. Le pilote graphique ne sait peut-être pas quelle forme et combien de temps les données retournées seront, mais la taille maximale est la taille complète de la charge utile pour le paquet final, y compris le FinalPacketExtraPayload. Le système d’exploitation valide que cette valeur n’est pas supérieure à la TargetMaximumReturnPacketSize valeur indiquée par le pilote dans ses fonctionnalités pour la cible, mais le pilote doit s’assurer à la fois que cette mémoire tampon n’est pas surutilisée par un périphérique signalant davantage de données et que les données du périphérique ne sont pas tronquées en raison d’une taille supérieure à la valeur MaximumReturnPacketSize actuellement appliquée au périphérique. Le pilote écrit le nombre d’octets lus dans la mémoire tampon dans le ReadWordCount champ décrivant la transmission.

Dans certains cas, le pilote graphique est forcé de réinitialiser l’interface de communication au panneau ou à l’ensemble du panneau en raison d’erreurs qui peuvent ne pas être liées au pilote du panneau OEM et qui peuvent ne pas être observables par le pilote de panneau OEM. Pour résoudre ce problème, le pilote doit signaler DXGK_HOST_DSI_INTERFACE_RESET ou DXGK_HOST_DSI_DEVICE_RESET définie dans le champ lors de la HostErrors première tentative de transmission après la réinitialisation afin que le pilote du panneau OEM puisse détecter la situation et récupérer. Le pilote ne doit pas envoyer cette transmission au matériel, mais le pilote du panneau OEM peut simplement réessayer la même commande si aucune récupération n’est requise, auquel cas le pilote doit poursuivre le traitement de la transmission comme d’habitude.

Fin d’une transmission

Lorsque l’IOCTL termine la FailedPacketcharge utile , ReadWordCount, MipiErrorsHostErrors et d’un paquet de lecture (final) peut avoir été mis à jour en fonction du résultat. Si des erreurs ont été détectées lors du traitement de la transmission, le pilote du panneau OEM doit utiliser les MipiErrors valeurs de sortie et HostErrors pour déterminer comment récupérer et continuer.

Pour garantir que la sortie est retournée à l’appelant afin de fournir des détails sur les erreurs éventuelles, les appels IOCTL et DDI doivent signaler une réussite, même si des erreurs sont détectées. La réussite n’indique pas que la transaction a réussi, elle indique que les appels pour gérer la transaction se sont déroulés comme prévu et que des indicateurs d’erreur ont été définis, le cas échéant. Des échecs peuvent toujours être signalés pour des conditions telles qu’un appel DDI non pris en charge (probablement en raison d’une incompatibilité de pilote), des échecs d’allocation de mémoire ou la transmission de paramètres complètement incorrects, tels que la transmission d’une mémoire tampon NULL. Si aucune erreur n’est signalée pour un appel réussi, l’appelant doit supposer que la transaction a réussi.