Compartilhar via

Configurando a transferência isócrona para dispositivos IEEE 1394

  • Artigo

Antes que os drivers possam iniciar o dispositivo, eles devem seguir estas etapas:

Etapa 1. Escolha a velocidade de transferência.

O barramento IEEE 1394 pode dar suporte a várias velocidades diferentes, limitadas pelo que o hardware permite. Mesmo que um dispositivo específico dê suporte a uma determinada velocidade, ele pode ser conectado a outro dispositivo que só dá suporte a velocidades mais baixas. Os drivers devem determinar em tempo de execução a velocidade de transferência entre o dispositivo e o computador. Eles consultam o motorista do ônibus com a solicitação REQUEST_GET_SPEED_BETWEEN_DEVICES para determinar a velocidade máxima possível entre dois dispositivos no ônibus ou o dispositivo e o computador host.

Etapa 2. Alocar largura de banda.

Antes que qualquer transferência de dados isócrona possa ocorrer, o motorista deve reservar largura de banda no ônibus. O barramento acompanha a quantidade de largura de banda alocada até atingir um valor fixo (de acordo com a especificação IEEEE 1394-1995, a largura de banda máxima que pode ser enviada é de 80% de uma ciclo de ônibus, que é de 125 nanossegundos); em seguida, ele não permite que nenhum outro dispositivo adquira largura de banda até que parte da largura de banda alocada no momento seja liberada. O motorista envia o REQUEST_ISOCH_ALLOCATE_BANDWIDTH solicitação ao motorista do ônibus para reservar largura de banda.

Se a solicitação for bem-sucedida, o motorista do ônibus retornará uma alça de largura de banda. O motorista usa esse identificador em solicitações futuras relacionadas à largura de banda para o motorista do ônibus. Por exemplo, o driver pode usar REQUEST_ISOCH_SET_CHANNEL_BANDWIDTH no identificador para ajustar a quantidade de largura de banda alocada. Quando o driver tiver terminado com a largura de banda alocada, ele deverá usar REQUEST_ISOCH_FREE_BANDWIDTH para liberar a largura de banda, para que ele possa ser usado por outros dispositivos no barramento.

Se a solicitação falhar, o driver não deverá tentar nenhuma transferência de dados. Os drivers que não alocarem largura de banda podem ser capazes de alocá-lo em tentativas subsequentes, portanto, eles devem deixar-se em um estado em que possam tentar alocar largura de banda mais tarde, quando apropriado. As tentativas de alocar largura de banda após uma redefinição de barramento provavelmente serão bem-sucedidas, pois o sistema libera automaticamente todos os canais e largura de banda alocados anteriormente após uma redefinição de barramento.

Os drivers que conseguem alocar largura de banda devem realocar sua largura de banda e canais após uma redefinição de barramento, pelos motivos mencionados. Além disso, após uma redefinição, os identificadores de largura de banda ficam obsoletos e devem ser liberados por uma chamada para REQUEST_ISOCH_FREE_BANDWIDTH, a menos que a largura de banda tenha sido alocada com o sinalizador IRB_FLAG_ALLOW_REMOTE_FREE definido.

Etapa 3. Alocar um canal.

Depois que uma solicitação de alocação de largura de banda for bem-sucedida, o driver solicitará um canal isócrono no qual gravar dados. Vários dispositivos podem ler pacotes em um canal isócrono, mas apenas um dispositivo pode gravar em um canal. Os dispositivos que recebem pacotes isócronos não enviam pacotes de confirmação em troca.

Os motoristas solicitam um canal enviando a solicitação REQUEST_ISOCH_ALLOCATE_CHANNEL para o motorista do ônibus. O driver pode solicitar um canal específico ou ISOCH_ANY_CHANNEL para alocar qualquer canal gratuito. Com êxito, o motorista do ônibus retorna o canal alocado. Se o motorista do ônibus retornar um código de erro, os drivers não deverão tentar nenhuma transferência de dados e devem desalocar a largura de banda alocada na Etapa 2.

Os drivers não devem assumir que, como um canal não está disponível no momento, ele nunca estará disponível. Os canais podem se tornar gratuitos a qualquer momento, portanto, os drivers devem deixar-se em um estado em que possam tentar alocar um canal mais tarde, quando apropriado.

Etapa 4. Alocar um identificador de recurso.

Depois que o driver aloca um canal, ele aloca um identificador de recurso para esse canal. Em todas as etapas subsequentes, o driver usa o identificador de recurso para especificar o canal.

Os motoristas alocam um identificador de recurso para o canal enviando a solicitação REQUEST_ISOCH_ALLOCATE_RESOURCES ao motorista do ônibus.

Quando o driver aloca um identificador de recurso, ele também especifica sinalizadores que indicam como os buffers anexados ao identificador serão usados:

Se essa solicitação falhar, os drivers deverão desalocar todos os recursos isocronos alocados nas etapas anteriores.

Etapa 5. Anexe buffers ao identificador de recurso.

Depois que o driver aloca um identificador de recurso, ele anexa buffers ao identificador. O controlador de DMA do host lerá dados ou gravará dados nos buffers anexados.

Com cada buffer, o driver passa uma estrutura ISOCH_DESCRIPTOR que descreve como o buffer será usado. Na estrutura ISOCH_DESCRIPTOR do buffer, o driver pode especificar as seguintes informações:

  • O número máximo de bytes por quadro. Ao transmitir dados, o controlador de host divide o buffer de dados em pacotes desse tamanho.

  • Uma rotina de retorno de chamada opcional. O motorista do ônibus chama essa rotina quando termina o processamento

  • Opções de sincronização. Consulte Opções de sincronização isocronas para dispositivos IEEE 1394 para obter uma descrição das opções de sincronização.

  • Em operações de conversa isocronas, o driver pode designar esse buffer como uma lista de cabeçalhos a serem anexados aos próximos pacotes de dados. Confira Opções de Conversa Isocrona para Dispositivos IEEE 1394 para obter detalhes.

Depois que a operação for iniciada, o driver poderá desanexar buffers que ele não precisa mais e pode anexar buffers adicionais. O motorista pode usar a rotina de retorno de chamada identificada em ISOCH_DESCRIPTOR para sinalizar a si mesmo quando o motorista do ônibus tiver concluído o processamento do último buffer anexado. Consulte Buffering Isochronous DMA Transfers for IEEE 1394 Devices for a description of DMA buffering for IEEE 1394 devices.

Etapa 6. Iniciar a transferência de dados

Para ler do dispositivo, o driver emite a solicitação REQUEST_ISOCH_LISTEN . Para gravar no dispositivo, o driver emite a solicitação REQUEST_ISOCH_TALK . Em seguida, o driver pode ativar o dispositivo para leitura ou gravação, da maneira apropriada específica do dispositivo.