IOCTL_MIPI_DSI_TRANSMISSION IOCTL (ntddvdeo.h)

Artigo
08/07/2023

Código principal: IRP_MJ_DEVICE_CONTROL

IOCTL_MIPI_DSI_TRANSMISSION é emitido para enviar uma sequência de pacotes DSI de MIPI para um periférico.

Código principal

IRP_MJ_DEVICE_CONTROL

Buffer de entrada

n/d

Comprimento do buffer de entrada

n/d

Buffer de saída

n/d

Comprimento do buffer de saída

n/d

Buffer de entrada/saída

Uma estrutura DXGK_DSI_TRANSMISSION seguida por estruturas DXGK_DSI_PACKET que contêm os pacotes.

Comprimento do buffer de entrada/saída

Pelo menos sizeof(DXGK_DSI_TRANSMISSION) + ((PacketCount - 1) * sizeof(DXGK_DSI_PACKET)) + FinalPacketExtraPayload. Consulte Comentários para obter detalhes.

Bloco de status

Irp->IoStatus.Status será definido como STATUS_SUCCESS se a solicitação for bem-sucedida. Caso contrário, Status será definido como a condição de erro apropriada como um código NTSTATUS. Para obter mais informações, consulte Valores NTSTATUS.

Comentários

Monitore, oem-panel e monitore drivers de porta/miniporte devem lidar com IOCTLs de interface serial digital (DSI) da Interface Serial Digital (MIPI) do Setor Móvel.

Executando transmissões

Para permitir que um driver de painel interaja por essa interface privada entre o adaptador gráfico e o hardware do painel, as transações não devem ter nenhum efeito de driver gráfico, exceto o tempo que ocupa o barramento ou devem ser totalmente definidas para que o driver gráfico esteja no controle. Como o ponto de permitir que um driver de painel interaja é fornecer suporte para recursos de painel personalizado que são opacos para o driver gráfico, as operações totalmente definidas destinam-se a ser restritas a transações em que o driver de painel precisa executar uma operação padronizada que não pode ser executada sem o envolvimento do driver gráfico. Essas transações serão tratadas como exceções roteadas explicitamente e não como transmissões.

Cada solicitação de transmissão consiste em um único buffer que é preenchido pelo driver do painel OEM, passado para baixo a pilha do monitor e retornado com os resultados da transmissão, se houver. O buffer contém informações gerais sobre a transmissão, com campos de entrada e saída, seguidos por uma matriz de tamanho variável de estruturas de DXGK_DSI_PACKET . Os pacotes são descritos em termos de DSI, de modo que qualquer pacote DSI possa ser descrito no entanto, o sistema operacional analisará os pacotes e rejeitará qualquer transmissão que inclua pacotes não permitidos. Todos os pacotes, exceto o último, são, por definição de DSI, pacotes de gravação que podem ser gravações curtas, nesse caso, o buffer de carga não usado ou gravações longas que se encaixam no buffer de carga . O último pacote em uma transmissão, que pode ser uma leitura ou uma gravação, tem permissão para usar uma carga estendida alocando e descrevendo um buffer maior que permitirá espaço para leituras ou gravações de qualquer tamanho até o limite de dados de pacote longo DSI de 64 K-1 bytes de dados. Isso permite que sequências de pacotes de gravação pequenos sejam enfileirados no driver em uma única chamada, mas exige que pacotes maiores sejam enviados individualmente. O valor do campo FinalPacketExtraPayload indica quantos bytes extras foram alocados, mas isso também deve ser contabilizado no campo TotalBufferSize .

O driver do painel OEM é responsável por garantir que as transmissões solicitadas não entrem em conflito ou interfiram com outras transmissões que o driver gráfico usa para interação normal com o painel devido a solicitações excessivas ou operações de solicitação que causariam atrasos no processamento de outras transmissões. O driver do painel não deve alterar nenhum estado que cause falhas subsequentes no driver gráfico, por exemplo, alterando o tempo do painel por meio de comandos MCS. Da mesma forma, se o sistema operacional solicitou uma alteração de exibição, por meio do driver gráfico, por exemplo, um aumento no brilho, o driver do painel não deve usar comandos DSI para desfazer essa alteração, seja em resposta ou para outras finalidades.

IOCTL_MIPI_DSI_TRANSMISSION é usado para solicitar uma transmissão para o periférico que contém um ou mais pacotes de DSI. O driver do painel deve sempre inicializar TotalBufferSize, PacketCount e os três primeiros BYTES de cada pacote. O driver do painel pode substituir o comportamento padrão usando valores não zero para TransmissionMode, ReportMipiErrors, ClearMipiErrors, SecondaryPort, ManufacturingMode e FinalCommandExtraPayload. Todos os valores não inicializados devem ser definidos como zero.

O sistema operacional garantirá que a sequência de pacotes DSI esteja bem formada, com informações válidas em todos os campos definidos e tamanhos de buffer corretos. O sistema operacional é responsável por inicializar o campo FailedPacket para DXGK_DSI_INVALID_PACKET_INDEX para que a validação adicional no sistema operacional ou driver só precise definir o campo se um problema for encontrado com um pacote específico. Se a estrutura DXGK_DSI_TRANSMISSION não estiver bem formada, o sistema operacional definirá o sinalizador DXGK_HOST_DSI_INVALID_TRANSMISSION no campo HostErrors para distinguir isso de outros erros de parâmetros inválidos.

Para ser considerado bem formado, todos os seguintes devem ser verdadeiros:

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
Somente o último pacote tem permissão para ser lido
Somente um pacote de gravação longa final pode ter um valor LongWriteWordCount maior que DXGK_DSI_PACKET_EMBEDDED_PAYLOAD_SIZE

Validação de pacote

Embora o sistema operacional não tente validar totalmente o conteúdo de todos os pacotes, ele rejeitará uma transmissão que contenha comandos DSI diferentes dos seguintes, concluindo o IOCTL sem chamar o driver gráfico:

Valor do tipo de dados	Descrição
0x03	Generic Short WRITE, sem parâmetros
0x13	Generic Short WRITE, 1 parâmetro
0x23	Generic Short WRITE, 2 parâmetros
0x04	LEITURA genérica, sem parâmetros
0x14	Leia genérico, 1 parâmetro
0x24	LEITURA Genérica, 2 parâmetros
0x05	DCS Short WRITE, sem parâmetros
0x15	DCS Short WRITE, 1 parâmetro
0x06	LEITURA DO DCS, sem parâmetros
0x29	Gravação Longa Genérica
0x39	Gravação/write_LUT longa do DCS

Comandos genéricos de leitura e gravação exigem compreensão da especificação do painel, portanto, a expectativa é que esses comandos possam ser usados livremente pelo driver do painel sem causar problemas para o driver gráfico, desde que o barramento não seja usado excessivamente. Da mesma forma, os comandos MCS do DCS são definidos explicitamente para uso do fabricante, portanto, não deve haver nenhum problema com a interferência entre o driver gráfico e o driver do painel.

Para o DCS UCS, não se espera que comandos indefinidos sejam usados pelo driver gráfico, portanto, o sistema operacional permitirá que eles sejam usados pelo driver de painel, embora haja claramente um risco de que futuras alterações de especificação MIPI-DCS definam o comando para que os comandos MCS sejam preferenciais.

Comandos DCS UCS padronizados serão usados pelo driver de gráficos durante a operação normal e potencialmente utilizáveis pelo driver de painel para que o risco de comandos enviados pelo driver do painel OEM causando problemas com os comandos do driver de gráficos subsequentes precise ser mitigado. Para fazer isso, o sistema operacional analisará os comandos DCS e rejeitará pacotes que devem causar conflitos, a menos que o driver do painel OEM defina o ManufacturingMode sinalizador e o sistema operacional confirme se o sistema está no modo de fabricação. Se o sinalizador estiver definido, mas o sistema não estiver no modo de fabricação, o IOCTL de transmissão será concluído com o sinalizador DXGK_HOST_DSI_INVALID_TRANSMISSION definido no HostErrors campo sem chamar o driver gráfico.

As condições que exigiriam uma transação totalmente definida em vez de usar uma transmissão seriam onde:

Períodos ociosos cronometrado são necessários antes ou depois, como DCS soft_reset
Alterando o ambiente operacional para saída de quadro, como set_vsync_timing dcs e enter_sleep_mode
Usar transações com semântica de início/continuação em que o driver gráfico também pode precisar acessar os mesmos dados, como DCS write_memory_start/write_memory_continue

Além disso, há classes de comandos DCS que serão rejeitadas pelo sistema operacional quando enviadas como uma transmissão:

Qualquer comando que precise ser totalmente definido, conforme descrito acima
Leituras de dados de pixel que podem ser usados para extração de tela
Gravações de dados de pixel

Comandos UCS pelos quais o sistema operacional passará para o driver gráfico

Hex	Comando
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

Comandos UCS que o sistema operacional rejeitará

Hex	Comando
01h	soft_reset - observe que isso deve ser enviado por meio de um 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

Observação

As políticas de validação do sistema operacional podem ser modificadas em versões futuras.

Implementação do driver gráfico

Se a transmissão passar pela validação do sistema operacional, o sistema operacional passará o buffer para o driver gráfico usando DsiTransmission.

Adicionar transmissões OEM em uma interface que já está sendo usada para enviar dados de pixel e controle com base em solicitações do sistema operacional e nas necessidades de controle periférico, inevitavelmente significa que o driver gráfico precisará aprimorar seu sequenciamento interno para garantir que esse fluxo adicional de pacotes possa ser incorporado corretamente. O driver gráfico não deve reordenar pacotes dentro de uma transmissão do driver do painel OEM e deve enviar toda a sequência ininterrupta e sem intercalação de outros pacotes. O driver gráfico não é necessário para manter a ordem de seus próprios pacotes em relação ao momento da chegada da solicitação de transmissão do painel OEM, portanto, pode optar por enviar pacotes para configurar o quadro a seguir antes (ou depois) de enviar uma transmissão de painel OEM. Se a conclusão de uma transmissão iniciada do painel OEM ameaça fazer com que os pacotes críticos percam a janela de tempo, o driver deverá relatar a transmissão como cancelada. Se uma transmissão não tiver sido iniciada, mas o driver esperar que ela faça com que os pacotes críticos percam a janela de tempo, o driver deverá adiar a inicialização da transmissão até o próximo período de espaço em branco. Se adiar uma transmissão de painel OEM faria com que ela estivesse aguardando mais de dois quadros iniciar, o driver deverá relatar a transmissão como descartada.

Não é possível que um driver gráfico garanta que as transmissões enviadas em nome do driver do painel não entrem em conflito com as transmissões sobre as quais ele tem controle. O driver pode optar por inspecionar pacotes dentro de uma transmissão e rejeitar a transmissão se eles causarem problemas, mas quaisquer pacotes considerados não seguros devem ser sinalizados para rejeição no nível do sistema operacional, portanto, a rejeição no nível do driver deve ser ideal devido a preocupações específicas do fornecedor de gráficos. O driver não deve tentar armazenar em cache nem otimizar leituras ou gravações, mesmo que os pacotes pareçam ser comandos padronizados.

Se o driver gráfico rejeitar uma transmissão devido a um problema com um pacote, ele deverá atualizar o FailedPacket campo com o índice do primeiro pacote, fazendo com que a transmissão seja rejeitada e definir o HostErrors sinalizador DXGK_HOST_DSI_DRIVER_REJECTED_PACKET antes de retornar. Se uma substituição de modo de transmissão for fornecida, o driver deverá verificar se a substituição é compatível com suas restrições de hardware e, caso contrário, defina o HostErrors sinalizador DXGK_HOST_DSI_BAD_TRANSMISSION_MODE antes de retornar.

Se ocorrer uma falha durante a comunicação, o driver gráfico deverá atualizar o FailedPacket campo com o índice do pacote que falhou, no entanto, pode não ser possível, em todos os casos, que o driver identifique o pacote para que o driver deixe o valor padrão, DXGK_DSI_INVALID_PACKET_INDEX, para esses casos.

O driver gráfico é responsável pela comunicação dos pacotes, portanto, deve garantir que todas as somas marcar sejam calculadas e verificadas. Qualquer transmissão que termine com uma leitura será um pacote curto, portanto, os campos Data0 e Data1 contêm parâmetros e a resposta pode ser um pacote curto ou longo. O driver gráfico pode não saber qual formulário e por quanto tempo os dados retornados ficarão, mas o tamanho máximo é o tamanho total do conteúdo do pacote final, incluindo o FinalPacketExtraPayload. O sistema operacional validará que esse valor não é maior do que o TargetMaximumReturnPacketSize relatado pelo driver em seus recursos para o destino, mas o driver deve garantir que esse buffer não seja invadido por um periférico relatando mais dados e que os dados do periférico não sejam truncados devido a serem maiores do que o MaximumReturnPacketSize atualmente aplicado ao periférico. O driver grava o número de bytes lidos no buffer no ReadWordCount campo que descreve a transmissão.

Pode haver casos em que o driver gráfico é forçado a redefinir a interface de comunicação para o painel ou todo o painel devido a erros que podem não estar relacionados e podem não ser observados para o driver do painel OEM. Para lidar com isso, o driver deve relatar DXGK_HOST_DSI_INTERFACE_RESET ou DXGK_HOST_DSI_DEVICE_RESET definidos no HostErrors campo na primeira tentativa de transmissão após a redefinição para que o driver do painel OEM possa detectar a situação e se recuperar. O driver não deve enviar essa transmissão para o hardware, mas o driver do painel OEM pode simplesmente repetir o mesmo comando se nenhuma recuperação for necessária, caso em que o driver deve prosseguir com o processamento da transmissão como de costume.

Concluindo uma transmissão

Quando o IOCTL conclui o FailedPacketconteúdo , ReadWordCount, MipiErrorsHostErrors e para um pacote de leitura (final) pode ter sido atualizado dependendo do resultado. Se forem encontrados erros durante o processamento da transmissão, o driver do painel OEM precisará usar os MipiErrors valores de saída e HostErrors para determinar como recuperar e continuar.

Para garantir que a saída seja retornada ao chamador para fornecer detalhes de quaisquer erros, as chamadas IOCTL e DDI precisam relatar um êxito, mesmo se forem encontrados erros. Êxito não indica que a transação foi bem-sucedida, indica que as chamadas para lidar com a transação prosseguiram conforme o esperado e os sinalizadores de erro foram definidos, se apropriado. Falhas ainda podem ser relatadas para condições como uma chamada DDI sem suporte (presumivelmente devido a uma incompatibilidade de driver), falhas de alocação de memória ou passagem de parâmetros completamente inválidos, como passar um buffer NULL. Se nenhum erro for relatado para uma chamada bem-sucedida, o chamador deverá assumir que a transação foi bem-sucedida.