IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)

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 :

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

Commandes UCS que le système d’exploitation rejettera

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.

Configuration requise

Voir aussi

DsiTransmission

DXGK_DSI_PACKET

DXGK_DSI_TRANSMISSION

IOCTL_MIPI_DSI_QUERY_CAPS

IOCTL_MIPI_DSI_RESET