Comandos de codec síncronos e assíncronos

A rotina TransferCodecVerbs permite que os drivers de função enviem comandos para codecs de áudio e modem conectados a um controlador de áudio HD. Os comandos do codec podem ser executados de forma síncrona ou assíncrona:

• Se uma chamada para TransferCodecVerbs enviar uma lista de comandos a serem processados de forma síncrona, a rotina retornará somente depois que o codec ou codecs tiverem processado todos os comandos.

• Se uma chamada para TransferCodecVerbs enviar uma lista de comandos a serem processados de forma assíncrona, a rotina retornará assim que o driver do barramento HD Audio adicionar os comandos à sua fila de comandos interna, sem esperar que o codec ou codecs processem os comandos. Depois que os codecs processam os comandos, o driver de barramento notifica o driver de função ao chamar uma rotina de callback.

Dependendo da natureza dos comandos do codec que ele envia, o driver de função usa uma ou mais das seguintes técnicas para recuperar respostas de um codec:

• Se o driver de função deve ter a resposta do codec antes de poder executar qualquer processamento adicional, ele usa o modo síncrono.

• Se o driver de função não precisar esperar que os comandos do codec sejam concluídos, para ver as respostas do codec e saber quando os comandos são concluídos, ele usa o modo assíncrono, ignora a rotina de retorno de chamada (exceto para liberar o armazenamento para os comandos do codec) e descarta ou ignora as respostas aos comandos do codec.

• Se o driver de função deve saber quando os comandos do codec são concluídos, mas não precisa ver as respostas, ele usa o modo assíncrono e depende da rotina de retorno de chamada para notificação. No entanto, ele descarta ou ignora as respostas aos comandos do codec. A sub-rotina de callback pode usar um evento de streaming do kernel (KS) para enviar a notificação para o componente principal do driver.

• Se o driver de função deve saber quando os comandos do codec são concluídos e quais são as respostas, mas deve retomar o processamento imediatamente em vez de esperar que os comandos sejam concluídos, ele usa o modo assíncrono e evita ler as respostas até receber a rotina de retorno de chamada. A rotina de retorno de chamada ou a parte principal do motorista pode inspecionar as respostas.

TransferCodecVerbs retorna STATUS_SUCCESS se conseguir adicionar a lista de comandos à fila de comandos interna do driver de barramento. Mesmo que a chamada seja bem-sucedida, as respostas ainda podem ser inválidas. O controlador de função deve verificar os bits de estado nas respostas do codec para determinar se são válidos. Esta regra aplica-se aos modos síncrono e assíncrono.

É provável que a causa de uma resposta inválida seja uma das seguintes:

• O comando não chegou ao codec.

• O codec respondeu, mas a resposta foi perdida quando ocorreu uma saturação de primeiro a entrar, primeiro a sair (FIFO) no RIRB.

Este último problema indica que o RIRB FIFO é de dimensão insuficiente.

Cada resposta de codec contém um sinalizador IsValid para indicar se a resposta é válida e um sinalizador HasFifoOverrun para indicar se ocorreu uma saturação de FIFO RIRB. Se IsValid = 0, indicando que uma resposta é inválida, o sinalizador HasFifoOverrun ajuda a identificar a origem da falha:

• Se HasFifoOverrun = 0, então o codec não conseguiu responder dentro do intervalo de tempo necessário. A causa provável é que o comando nunca chegou ao codec.

• Se HasFifoOverrun = 1, então o comando provavelmente atingiu o codec, mas a resposta foi perdida devido a uma saturação FIFO.

Durante uma chamada para TransferCodecCommands, o chamador fornece um ponteiro para uma matriz de HDAUDIO_CODEC_TRANSFER estruturas. Cada estrutura contém um comando e fornece espaço para uma resposta. O motorista do ônibus sempre grava cada resposta na estrutura que contém o comando que disparou a resposta.

Para cada chamada para TransferCodecCommands, a ordem em que os comandos são processados é determinada pela ordem dos comandos na matriz. O processamento do primeiro comando na matriz sempre é concluído antes do início do processamento do segundo comando, e assim por diante.

Além disso, se um cliente fizer uma chamada assíncrona para TransferCodecCommands e, em seguida, chamar TransferCodecCommands uma segunda vez sem esperar pela rotina de retorno de chamada da primeira chamada, a ordem relativa na qual os dois grupos de comandos das duas chamadas são processados é definida pela ordem em que o cliente enviou os dois grupos de comandos. Assim, o controlador de barramento processa todos os comandos da primeira chamada antes de começar a processar os comandos da segunda chamada.

No entanto, a ordem relativa dos comandos enviados por duas instâncias de driver de função diferentes é indefinida. (Cada instância tem seu próprio objeto de dispositivo físico.) Por exemplo, se a instância 1 chamar TransferCodecCommands para enviar comandos A, B e C na ordem A-B-C, e a instância 2 chamar TransferCodecCommands para enviar comandos X, Y e Z na ordem X-Y-Z, o driver de barramento poderá executar os comandos na ordem A-X-Y-B-Z-C.

Quando threads de driver de função separados compartilham acesso ao mesmo conjunto de recursos de hardware, a ordem relativa de comandos de threads de driver diferentes pode ser importante. Em caso afirmativo, o driver de função é responsável por sincronizar o compartilhamento dos recursos entre os threads.

Por exemplo, a interface de hardware para gravar uma sequência de bytes de dados em um codec pode consistir em um registro de índice e um registro de dados de 8 bits. Primeiro, o controlador de função envia um comando codec para carregar o índice inicial no registo de índice. Em seguida, o driver envia um comando para gravar o primeiro byte de dados no registro de dados. O registro de índice aumenta após cada gravação sucessiva no registro de dados até que a transferência seja concluída. No entanto, se dois threads de driver não conseguirem sincronizar corretamente seu acesso ao índice e aos registros de dados, a ordem relativa do acesso ao registro individual pelos dois threads será indefinida e o resultado provável será corrupção de dados ou uma configuração de hardware inválida.

A rotina TransferCodecVerbs está disponível em ambas as versões do HD Audio DDI.