IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntdvertitaeo.h)

Codice principale: IRP_MJ_DEVICE_CONTROL

IOCTL_MIPI_DSI_TRANSMISSION viene emesso per inviare una sequenza di pacchetti DSI MIPI a una periferica.

Codice principale

IRP_MJ_DEVICE_CONTROL

Buffer di input

n/d

Lunghezza del buffer di input

n/d

Buffer di output

n/d

Lunghezza del buffer di output

n/d

Buffer di input/output

Struttura DXGK_DSI_TRANSMISSION seguita da strutture DXGK_DSI_PACKET contenenti i pacchetti.

Lunghezza del buffer di input/output

Almeno sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload. Per ulteriori informazioni, vedere Note.

Blocco dello stato

Irp->IoStatus.Status è impostato su STATUS_SUCCESS se la richiesta ha esito positivo. In caso contrario, status è impostato sulla condizione di errore appropriata come codice NTSTATUS. Per altre informazioni, vedere Valori NTSTATUS.

Commenti

IOCTL IOCT (Mobile Industry Processor Interface, MIPI) Digital Serial Interface (DSI) devono gestire i driver porta/miniport monitor, pannello OEM e display.

Esecuzione di trasmissioni

Per consentire a un driver del pannello di interagire su questa interfaccia privata diversamente tra la scheda grafica e l'hardware del pannello, le transazioni devono non avere alcun effetto driver grafico, diversamente dal tempo occupato dal bus, oppure devono essere completamente definite in modo che il driver grafico sia controllato. Poiché il punto di consentire a un driver del pannello di interagire consiste nel fornire supporto per le funzionalità del pannello personalizzate che sono opache per il driver grafico, le operazioni completamente definite devono essere limitate alle transazioni in cui il driver del pannello deve eseguire un'operazione standardizzata che non può essere eseguita senza il coinvolgimento del driver grafico. Tali transazioni verranno considerate come eccezioni indirizzate in modo esplicito anziché come trasmissioni.

Ogni richiesta di trasmissione è costituita da un singolo buffer che viene riempito dal driver del pannello OEM, passato lo stack di monitoraggio e restituito con i risultati della trasmissione, se presente. Il buffer contiene informazioni generali sulla trasmissione, con campi di input e output, seguiti da una matrice di dimensioni variabili di strutture DXGK_DSI_PACKET . I pacchetti sono descritti in termini DSI, in modo che qualsiasi pacchetto DSI possa essere descritto, tuttavia il sistema operativo analizzerà i pacchetti e rifiuterà qualsiasi trasmissione che include pacchetti non consentiti. Tutti i pacchetti tranne l'ultimo sono, per definizione DSI, i pacchetti di scrittura che possono essere brevi scritture, nel qual caso il buffer del payload non è usato o le scritture lunghe che rientrano nel buffer payload . L'ultimo pacchetto in una trasmissione, che può essere una lettura o una scrittura, può usare un payload esteso allocando e descrivendo un buffer più grande che consente la lettura o le scritture di qualsiasi dimensione fino al limite di dati del pacchetto lungo DSI di 64K-1 byte di dati. In questo modo, le sequenze di pacchetti di scrittura di piccole dimensioni devono essere accodate al driver in una singola chiamata, ma richiedono che i pacchetti più grandi vengano inviati singolarmente. Il valore del campo FinalPacketExtraPayload indica il numero di byte aggiuntivi allocati, ma deve essere tenuto conto anche nel campo TotalBufferSize .

Il driver del pannello OEM è responsabile di garantire che le trasmissioni richieste non siano in conflitto o interferiscano con altre trasmissioni usate dal driver grafico per l'interazione normale con il pannello a causa di richieste eccessive o richieste di operazioni che potrebbero causare ritardi nell'elaborazione di altre trasmissioni. Il driver del pannello non deve modificare alcuno stato che provocherebbe errori successivi nel driver grafico, ad esempio modificando l'intervallo del pannello tramite i comandi MCS. Analogamente, se il sistema operativo ha richiesto una modifica di visualizzazione, tramite il driver grafico, ad esempio un aumento della luminosità, il driver del pannello non deve usare i comandi DSI per annullare tale modifica, in risposta o per altri scopi.

IOCTL_MIPI_DSI_TRANSMISSION viene usato per richiedere una trasmissione alla periferica contenente uno o più pacchetti DSI. Il driver del pannello deve sempre inizializzare TotalBufferSize, PacketCount e i primi tre BYTE di ogni pacchetto. Il driver del pannello può eseguire l'override del comportamento predefinito usando valori diversi da zero per TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode e FinalCommandExtraPayload. Tutti i valori non inizializzati devono essere impostati su zero.

Il sistema operativo garantisce che la sequenza di pacchetti DSI sia ben formata, con informazioni valide in tutti i campi definiti e dimensioni corrette del buffer. Il sistema operativo è responsabile dell'inizializzazione del campo FailedPacket in modo da DXGK_DSI_INVALID_PACKET_INDEX in modo che un'ulteriore convalida nel sistema operativo o nel driver debba impostare il campo solo se viene rilevato un problema con un pacchetto specifico. Se la struttura DXGK_DSI_TRANSMISSION non è ben formata, il sistema operativo imposterà il flag DXGK_HOST_DSI_INVALID_TRANSMISSION nel campo HostErrors per distinguere questo da altri errori di parametri non validi.

Per essere considerato ben formato, il seguente deve essere tutto vero:

• 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 l'ultimo pacchetto può essere una lettura
• Solo un pacchetto di scrittura lungo finale può avere un valore LongWriteWordCount maggiore di DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE

Convalida dei pacchetti

Anche se il sistema operativo non tenterà di convalidare completamente il contenuto di tutti i pacchetti, rifiuterà una trasmissione contenente comandi DSI diversi dal seguente, completando IOCTL senza chiamare il driver grafico:

I comandi generici di lettura e scrittura richiedono la comprensione della specifica del pannello, in modo che l'aspettativa sia che questi comandi possano essere usati liberamente dal driver del pannello senza causare problemi per il driver grafico, purché il bus non venga utilizzato eccessivamente. Analogamente, i comandi MCS DCS vengono definiti in modo esplicito per l'uso da parte del produttore, pertanto non dovrebbe esserci alcun problema con l'interferenza tra il driver grafico e il driver del pannello.

Per DCS UCS, i comandi non definiti non devono essere usati dal driver grafico, quindi il sistema operativo consentirà di usarli dal driver del pannello, anche se esiste chiaramente un rischio che le modifiche alle specifiche MIPI-DCS future definiscano il comando in modo che i comandi MCS siano preferiti.

I comandi UCS DCS standardizzati verranno usati dal driver grafico durante il normale funzionamento e sono potenzialmente utilizzabili dal driver del pannello in modo che il rischio di comandi inviati dal driver del pannello OEM che causano problemi con i comandi successivi del driver del driver grafico devono essere mitigati. A tale scopo, il sistema operativo analizzerà i comandi DCS e rifiuterà i pacchetti che dovrebbero causare conflitti a meno che il driver del pannello OEM non imposti il ManufacturingMode flag e il sistema operativo conferma che il sistema è in modalità di produzione. Se il flag è impostato ma il sistema non è in modalità di produzione, la trasmissione IOCTL verrà completata con il flag DXGK_HOST_DSI_INVALID_TRANSMISSION impostato nel HostErrors campo senza chiamare il driver grafico.

Le condizioni che richiedono una transazione completamente definita invece di usare una trasmissione sono le seguenti:

• I periodi di inattività temporali sono necessari prima o dopo, ad esempio DCS soft_reset
• Modifica dell'ambiente operativo per l'output dei frame, ad esempio dcs set_vsync_timing e enter_sleep_mode
• Uso delle transazioni con semantica di inizio/continuazione in cui il driver grafico può anche dover accedere agli stessi dati, ad esempio DCS write_memory_start/write_memory_continue

Inoltre, esistono classi di comandi DCS che verranno rifiutati dal sistema operativo quando inviati come trasmissione:

• Qualsiasi comando che deve essere completamente definito, come descritto in precedenza
• Letture di dati pixel che possono essere usati per lo scraping dello schermo
• Scritture di dati pixel

Comandi UCS che il sistema operativo passerà al driver grafico

Comandi UCS che il sistema operativo rifiuterà

Implementazione del driver grafico

Se la trasmissione supera la convalida del sistema operativo, il sistema operativo passa il buffer al driver grafico usando DsiTransmission.

L'aggiunta di trasmissioni OEM in un'interfaccia già usata per inviare dati sia pixel che di controllo in base alle richieste del sistema operativo e alle esigenze del controllo delle periferiche, significa inevitabilmente che il driver grafico dovrà migliorare la sequenziazione interna per garantire che questo flusso aggiuntivo di pacchetti possa essere incorporato correttamente. Il driver grafico non deve riordinare i pacchetti all'interno di una trasmissione dal driver del pannello OEM e deve inviare l'intera sequenza senza interruzioni e senza interleaving di altri pacchetti. Il driver grafico non è necessario per mantenere l'ordine dei propri pacchetti in relazione al momento dell'arrivo della richiesta di trasmissione del pannello OEM, quindi può scegliere di inviare pacchetti per impostare il frame seguente prima (o dopo) di inviare una trasmissione del pannello OEM. Se il completamento di una trasmissione del pannello OEM avviato minaccia di causare la mancata scadenza dei pacchetti critici, il driver deve segnalare la trasmissione come annullata. Se una trasmissione non è stata avviata, ma il conducente si aspetta che i pacchetti critici non perdano l'intervallo di tempo, il conducente deve rinviare l'avvio della trasmissione fino al successivo periodo di vuoto. Se il rinvio di una trasmissione del pannello OEM avrebbe causato l'avvio di più di due fotogrammi, il driver dovrebbe segnalare la trasmissione come eliminata.

Non è possibile che un driver grafico assicuri che le trasmissioni inviate per conto del driver del pannello non siano in conflitto con le trasmissioni su cui ha il controllo. Il driver può scegliere di controllare i pacchetti all'interno di una trasmissione e rifiutare la trasmissione se causerebbero problemi, ma eventuali pacchetti considerati non sicuri devono essere contrassegnati per il rifiuto a livello di sistema operativo, quindi il rifiuto a livello di driver dovrebbe essere idealmente dovuto a problemi specifici del fornitore di grafica. Il driver non deve tentare di memorizzare nella cache o ottimizzare letture o scritture, anche se i pacchetti sembrano essere comandi standardizzati.

Se il driver grafico rifiuta una trasmissione a causa di un problema con un pacchetto, deve aggiornare il FailedPacket campo con l'indice del primo pacchetto, causando il rifiuto della trasmissione e l'impostazione del HostErrors flag DXGK_HOST_DSI_DRIVER_REJECTED_PACKET prima della restituzione. Se viene fornito un override della modalità di trasmissione, il driver deve verificare che l'override sia compatibile con i vincoli hardware e, in caso contrario, impostare il HostErrors flag di DXGK_HOST_DSI_BAD_TRANSMISSION_MODE prima di restituire.

Se si verifica un errore durante la comunicazione, il driver grafico deve aggiornare il FailedPacket campo con l'indice del pacchetto che non è riuscito, tuttavia potrebbe non essere possibile in tutti i casi per consentire al driver di identificare il pacchetto in modo che il driver lasci il valore predefinito, DXGK_DSI_INVALID_PACKET_INDEX, per tali casi.

Il driver grafico è responsabile della comunicazione dei pacchetti, quindi deve garantire che le somme di controllo vengano calcolate e verificate. Qualsiasi trasmissione che termina con una lettura sarà un pacchetto breve, quindi i campi Data0 e Data1 contengono parametri e la risposta può essere un pacchetto breve o lungo. Il driver grafico potrebbe non sapere quale modulo e quanto tempo saranno i dati restituiti, ma la dimensione massima è la dimensione massima del payload per il pacchetto finale, incluso .FinalPacketExtraPayload Il sistema operativo convaliderà che questo valore non è maggiore di quello TargetMaximumReturnPacketSize segnalato dal driver nelle relative funzionalità per la destinazione, ma il driver deve garantire che questo buffer non venga sovraccaricato da una periferica che segnala più dati e che i dati della periferica non vengano troncati a causa di dimensioni maggiori rispetto a MaximumReturnPacketSize attualmente applicate alla periferica. Il driver scrive il numero di byte letti nel buffer nel ReadWordCount campo che descrive la trasmissione.

Ci possono essere casi in cui il driver grafico è costretto a reimpostare l'interfaccia di comunicazione al pannello o l'intero pannello a causa di errori che potrebbero non essere correlati a e potrebbero non essere osservabili al driver del pannello OEM. Per risolvere questo problema, il driver deve segnalare DXGK_HOST_DSI_INTERFACE_RESET o DXGK_HOST_DSI_DEVICE_RESET impostato nel campo nel HostErrors primo tentativo di trasmissione dopo la reimpostazione in modo che il driver del pannello OEM possa rilevare la situazione e il ripristino. Il driver non deve inviare questa trasmissione all'hardware, ma il driver del pannello OEM può semplicemente ripetere lo stesso comando se non è necessario alcun ripristino, nel qual caso il driver deve procedere con l'elaborazione della trasmissione come di consueto.

Completamento di una trasmissione

Quando IOCTL completa il FailedPacketpayload , ReadWordCount, MipiErrorsHostErrors e per un pacchetto di lettura (finale) potrebbe essere stato aggiornato a seconda del risultato. Se sono stati rilevati errori durante l'elaborazione della trasmissione, il driver del pannello OEM deve usare i MipiErrors valori di output e HostErrors per determinare come ripristinare e procedere.

Per assicurarsi che l'output venga restituito al chiamante per fornire i dettagli di eventuali errori, le chiamate IOCTL e DDI devono segnalare un esito positivo, anche se vengono rilevati errori. L'esito positivo non indica che la transazione ha avuto esito positivo, indica che le chiamate per gestire la transazione procedevano come previsto e che sono stati impostati flag di errore, se appropriato. Gli errori possono comunque essere segnalati per condizioni come una chiamata DDI non supportata (presumibilmente a causa di una mancata corrispondenza del driver), errori di allocazione della memoria o passaggio di parametri completamente non valido, ad esempio il passaggio di un buffer NULL. Se non vengono segnalati errori per una chiamata riuscita, il chiamante deve presupporre che la transazione abbia avuto esito positivo.

Requisiti

Vedi anche

DsiTransmission

DXGK_DSI_PACKET

DXGK_DSI_TRANSMISSION

IOCTL_MIPI_DSI_QUERY_CAPS

IOCTL_MIPI_DSI_RESET