Outros objetos de namespace ACPI

Para algumas classes específicas do dispositivo, há requisitos para que objetos de namespace ACPI (Configuração Avançada e Power Interface) adicionais apareçam nesses dispositivos no namespace. Esta seção lista os objetos adicionais necessários para plataformas baseadas em SoC.

Objetos de identificação do processador

Os processadores devem ser enumerados no namespace ACPI. Os processadores são declarados em \_SB usando a instrução "Device", como acontece com outros dispositivos na plataforma. Os dispositivos de processador devem conter os seguintes objetos:

• _HID: ACPI0007
• _UID: um número exclusivo que corresponde à entrada do processador no MADT.

Objetos específicos à exibição

Para obter mais informações sobre objetos específicos à exibição, consulte Apêndice B, "Extensões de Vídeo", da especificação ACPI 5.0.

Requisitos do objeto Display-Specific

Controladores e dispositivos de host USB

Os controladores de host USB são usados em plataformas SoC para conectar dispositivos internos e externos. O Windows inclui drivers embutidos para controladores de host USB padrão que estão em conformidade com as especificações EHCI ou XHCI.

Em plataformas baseadas em SoC, o controlador de host USB pode ser enumerado pelo ACPI. O Windows usa os seguintes objetos de namespace ACPI ao enumerar e configurar o hardware USB compatível:

• Uma ID de Hardware compatível com ACPI atribuída pelo fornecedor (_HID).

• Um objeto ID Exclusivo (_UID), se houver mais de uma instância do controlador USB no namespace (ou seja, dois ou mais nós que têm objetos de identificação de dispositivo idênticos).

• Uma ID compatível (_CID) para o controlador de host USB compatível com EHCI ou XHCI Standard (EHCI: PNP0D20) (XHCI: PNP0D10).

• As Configurações de Recurso Atual (_CRS) atribuídas ao controlador USB. Os recursos do controlador são descritos na especificação de interface de hardware apropriada (EHCI ou XHCI).

Método Device-Specific USB (_DSM)

O Windows define um método Device-Specific (_DSM) para dar suporte à configuração específica da classe de dispositivo do subsistema USB. Para obter mais informações, consulte o Método Device-Specific USB.

Suporte ao tradutor de transações integrado USB (TT) (_HRV)

Os controladores de host EHCI padrão dão suporte apenas a dispositivos USB de alta velocidade. Em plataformas SoC, o Windows dá suporte a dois designs comuns de controladores de host compatíveis com EHCI que implementam um tradutor de transações integrado para dispositivos USB de baixa velocidade e velocidade total. O objeto de Revisão de Hardware (_HRV) indica o tipo de suporte TT integrado ao driver do controlador de host USB.

O _HRV é definido de acordo com os seguintes critérios:

• NoIntegratedTT - _HRV = 0

  Os controladores de host EHCI padrão não implementam tradutores de transação integrados e um valor de _HRV de 0 é válido apenas para esses controladores. Não é necessário incluir o objeto _HRV para esses controladores.

• IntegratedTTSpeedInPortSc - _HRV = 1

  Habilite o suporte TT integrado. Esse tipo de interface inclui os bits LowSpeed e HiSpeed no próprio registro PORTSC. Esses bits estão nos deslocamentos de bits 26 e 27, respectivamente. Ao determinar a velocidade, o driver EHCI lerá o PORTSC e extrairá as informações de velocidade desses bits.

• IntegratedTTSpeedInHostPc – _HRV = 2

  Habilite o suporte TT integrado. Esse tipo de interface inclui os bits LowSpeed e HiSpeed em um registro HOSTPC separado. Quando o driver EHCI precisar determinar a velocidade da porta, ele lerá o registro HOSTPC correspondente à porta de interesse e extrairá as informações de velocidade.

Suporte a USB XHCI D3cold

Além da suspensão seletiva, os dispositivos USB internos conectados aos controladores XHCI podem ser configurados para o estado D3cold e desligados quando não estão em uso. Para obter mais informações, consulte Gerenciamento de Energia do Dispositivo. Todos os drivers de função de dispositivo USB devem aderir ao D3cold.

Objetos específicos da porta USB

O Windows precisa saber a visibilidade e a capacidade de conexão das portas USB no sistema. Isso é necessário para fornecer informações precisas ao usuário sobre portas e dispositivos. Dois objetos, o Local do Dispositivo Físico (_PLD) e os Recursos de Porta USB (_UPC), são usados para essa finalidade. Para obter mais informações, consulte o seguinte:

• Seções 6.1.6, "Objetos de Identificação do Dispositivo" e 9.13.1, "Controladores de Host USB 2.0 e _UPC e _PLD", na especificação ACPI 5.0.

• Usando o ACPI para configurar portas USB em um computador.

Controladores e dispositivos de host SD

Os controladores de host SD são usados em plataformas SoC para acesso ao armazenamento, bem como dispositivos de E/S. O Windows inclui um driver interno para hardware de controlador de host padrão SDA. Para compatibilidade com esse driver, um dispositivo controlador de host SD deve estar em conformidade com a Especificação do Controlador de Host SD da Associação SD.

Em plataformas SoC, o controlador de host SD pode ser enumerado pela ACPI. O Windows usa os seguintes objetos de namespace ACPI ao enumerar e configurar hardware SD compatível:

• Uma ID de Hardware compatível com ACPI atribuída pelo fornecedor (_HID).

• Um objeto ID Exclusivo (_UID), se houver mais de uma instância do controlador SD no namespace (ou seja, dois ou mais nós que têm objetos de identificação de dispositivo idênticos).

• Uma ID compatível (_CID) para o controlador de host SD em conformidade com o padrão SDA (PNP0D40).

• As Configurações de Recurso Atual (_CRS) atribuídas ao controlador. Os recursos do controlador são descritos da seguinte maneira:

  • Os recursos de hardware para todos os slots implementados estão incluídos. Um slot é um ponto de conexão no barramento SDIO para um dispositivo de E/S ou memória. Cada slot é associado a um conjunto padrão de registros e uma interrupção no controlador de host SD, que são usados para comunicação com o dispositivo conectado. Os controladores de host SD podem implementar qualquer número de slots, mas em plataformas SoC, normalmente há apenas um.

  • Os recursos de slot são listados juntos, em ordem de número de slot (os recursos do slot 0 são os primeiros, os recursos do slot 1 são os segundos e assim por diante).

  • Para cada slot, os recursos são listados na seguinte ordem:

    • O endereço base do registro padrão do SD definido para o slot.

    • A interrupção padrão do SD para o slot.

    • Um recurso de interrupção de GPIO para o slot, utilizado para sinalizar inserções e remoções de cartão (caso a interface padrão de detecção de cartão SD não seja suportada em todos os estados de energia).

    • Um recurso de entrada GPIO para o slot, destinado a verificar se um cartão está atualmente inserido no slot (caso a interface padrão de detecção de cartão SD não seja suportada em todos os estados de energia). Usa o mesmo pino usado na interrupção de inserção/remoção.

    • Um segundo recurso de entrada GPIO para ler se o cartão no slot está protegido contra gravação (se a interface padrão de proteção contra gravação SD não é suportada durante todos os estados de energia).

As interrupções devem ser capazes de ativação (descritas como "SharedAndWake" ou "ExclusiveAndWake").

Dispositivos SD inseridos

Os dispositivos conectados ao SD são enumerados pelo driver de barramento SD. Os dispositivos SD integrados à plataforma também devem ser listados no namespace ACPI como filhos do controlador de host SD. Esse requisito permite que o sistema operacional associe o dispositivo enumerado por barramento aos atributos específicos da plataforma fornecidos para o dispositivo por objetos ACPI (por exemplo, impossibilidade de remoção, estados de energia do dispositivo, recursos GPIO ou SPB em uso e assim por diante). Para fazer essa associação, o namespace do dispositivo requer o objeto Address (_ADR), que comunica o endereço do dispositivo no barramento SDIO. O objeto _ADR retorna um inteiro.

Para o barramento SDIO, o valor desse inteiro é definido da seguinte maneira:

• Palavra alta – Número do slot (0 – primeiro slot)

• Palavra baixa – Número da função (consulte a especificação do SD para definições.)

Um namespace de dispositivo SD inserido também deve incluir:

• Um objeto remove (_RMV) que retorna 0 (para indicar que o dispositivo não pode ser removido).

• Um objeto _CRS para os recursos de sideband que o dispositivo requer (como pinos GPIO ou conexões SPB), se for necessário.

Dispositivos de captura de imagem (câmeras)

Os dispositivos de câmera podem ser enumerados pelo driver gráfico ou por USB. Em ambos os casos, o Windows precisa saber a localização física da câmera para que a interface do usuário apropriada possa ser mostrada. Para fazer isso, os dispositivos de câmera integrados ao chassi do sistema e que têm direção mecanicamente fixa são incluídos no namespace ACPI e fornecem o objeto Local do Dispositivo Físico (_PLD). Isso requer:

• O dispositivo de câmera deve aparecer como um filho (dispositivo aninhado) do dispositivo enumerador (seja o dispositivo GPU ou o dispositivo USB).

• O dispositivo de câmera destina-se a fornecer o objeto Address (_ADR) que contém o endereço da câmera no barramento do dispositivo pai.

  • Para USB, consulte a hierarquia de namespace do ACPI e _ADR para dispositivos USB inseridos na próxima seção abaixo.

  • Para elementos gráficos, esse é o identificador especificado no método _DOD fornecido no dispositivo GPU. Para obter mais informações, consulte Apêndice B, "Extensões de Vídeo", da especificação ACPI 5.0.

• Dispositivo de câmera para fornecer o objeto _PLD.

• Se houver recursos auxiliares exigidos pelo driver da câmera (como interrupção de GPIO, conexões de E/S ou uma conexão SPB), o objeto _CRS será fornecido para esses recursos.

No objeto _PLD, o campo Painel (bits 67-69), o campo Tampa (bit 66) e o campo Dock (bit 65) são definidos como valores corretos para a superfície na qual a câmera está montada. Todos os outros campos são opcionais. Para dispositivos móveis portáteis, incluindo tablets, o painel frontal é aquele que mantém a tela de exibição e sua origem fica no canto inferior esquerdo quando a exibição é exibida na orientação retrato. Usando essa referência, "Front" indica que a câmera está voltada para o usuário (webcam), enquanto "Traseira" indica que a câmera se volta para longe do usuário (câmera de foto ou vídeo). Para obter mais informações, consulte a seção 6.1.8, "_PLD (Local físico do dispositivo)", na especificação ACPI 5.0.

Hierarquia de namespace do ACPI e _ADR para dispositivos USB inseridos

Ao adicionar dispositivos USB inseridos ao namespace ACPI, a hierarquia dos nós de dispositivo deve corresponder exatamente à dos dispositivos que são enumerados pelo driver USB do Windows. Isso pode ser determinado examinando o Gerenciador de Dispositivos do Windows em seu modo "Exibição por Conexão". Toda a hierarquia, começando pelo controlador de host USB e estendendo-se até o dispositivo inserido, deve ser incluída. A propriedade "Address" fornecida no Gerenciador de Dispositivos para cada dispositivo é o endereço que o firmware deve relatar no _ADR do dispositivo.

A especificação ACPI 5.0 define os endereços para dispositivos USB da seguinte maneira:

HUB Raiz USB: filho somente do controlador anfitrião. Deve ter um _ADR de 0. Nenhum outro filho ou valores de _ADR são permitidos.

Portas USB: número da porta (1-n)

Dispositivos USB conectados a uma porta específica compartilham o endereço dessa porta.

Se o dispositivo conectado a uma porta for um dispositivo USB composto, as funções dentro do dispositivo composto deverão usar o seguinte endereço:

Função USB em um dispositivo USB composto: número de porta da porta à qual o dispositivo composto está conectado, MAIS o primeiro número de interface da função. (Adição aritmética).

Para obter mais informações, consulte Identificar o local das câmeras internas.

Exemplos de código ASL

O exemplo de código ASL a seguir descreve uma webcam USB que está conectada diretamente à porta USB 3.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {         // the Root HUB
     Name (_ADR, ZERO)      // Address is always 0.
     Device (CAM0) {          // Camera connected directly to USB
                       //   port number 3 under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
    } // End of Root Hub Device
}  // End of EHCI device

O exemplo de código ASL a seguir descreve um dispositivo composto USB que implementa uma webcam como Função 2.

Device (EHCI) {
    ...  // Objects required for EHCI devices
    Device {RHUB) {
     Name (_ADR, ZERO)
     Device (CUSB) {        // Composite USB device
                    //   connected to USB port number 3
                    //   under the Root.
            Name (_ADR, 3)      // Address is the same as the port.
            Device (CAM0) { // Camera function within the
                    //   Composite USB device.
                Name (_ADR, 5)  // Camera function has a first
                    //   Interface number of 2, so
                    //   Address is 3 + 2  = 5.
                Method (_PLD, 0, Serialized) {...}
            }  //  End of Camera device
        } // End of Composite USB Device
    } // End of Root Hub Device
}  // End of EHCI device

O exemplo de código ASL a seguir descreve uma webcam conectada por I2C.

Device (GPU0) {
    ... // Other objects required for graphics devices
    Name (_DOD, Package ()  // Identifies the children of this graphics device.
                // Each integer must be unique within the GPU0 namespace.
                {
                    0x00024321,  // The ID for CAM0. It is a non-VGA
                    //   device, cannot be detected by
                    //   the VGA BIOS, and uses a vendor-
                    //   specific ID format in bits 15:0
                    //   (see the _DOD specification).
                    ...     // Other child device IDs (for
                    //   example, display output ports)
                })
    Device (CAM0) {
        Name (_ADR, 0x00024321) // The identifier for this device
                    //   (Same as in _DOD above)
        Name (_CRS, ResourceTemplate()
            {
            // I2C Resource
            // GPIO interrupt resource(s), if required by
            //   driver
            // GPIO I/O resource(s), if required by driver
                ...
            })
        Method (_PLD, 0, Serialized) {...}
    } // End of CAM0 device
} // End of GPU0 device

Dispositivos HID-over-I2C

O Windows inclui um driver de classe para HID (Dispositivos de Interface Humana). Esse driver permite suporte genérico para uma ampla gama de dispositivos de entrada (como painéis de toque, teclados, mouses e sensores). Em plataformas SoC, os dispositivos HID podem ser conectados à plataforma por I2C e enumerados pela ACPI. Para compatibilidade com o suporte à classe HID no Windows, os seguintes objetos de namespace são usados:

• Um _HID específico do fornecedor

• Um _CID de PNP0C50

• Um _CRS com:

  • Um recurso I2CSerialBusConnection para acesso ao dispositivo

  • Um recurso gpioInt para interrupções

• O método _DSM HIDI2C para retornar o endereço do Registro do Descritor HID no dispositivo. Para obter mais informações, consulte o Método de Device-Specific HIDI2C (_DSM).

Dispositivos de botão

Para plataformas SoC, o Windows dá suporte ao Botão de Energia do Método de Controle definido pelo ACPI, bem como a uma matriz de cinco botões compatível com Windows. O botão de energia, seja implementado como um botão de energia do método de controle ACPI ou como parte da Matriz de Botões compatível com o Windows, faz o seguinte:

• Faz com que a plataforma seja ativada se ela estiver desativada.

• Gera o evento Power Button Override quando pressionado. Para obter mais informações, consulte a seção 4.8.2.2.1.3, "Substituição do Botão de Energia", da especificação ACPI 5.0.

Botão de energia do método control

Os designs do Clamshell e outros sistemas com teclados internos ou conectados implementam o Botão de Energia do Método de Controle definido por ACPI (seção 4.8.2.2.1.2 da especificação ACPI 5.0) usando GPIO-Signaled Eventos ACPI (seção 5.6.5 da especificação ACPI 5.0). Para dar suporte ao dispositivo do botão de energia, use o namespace:

• Descreve o pino de interrupção GPIO do botão de energia como um recurso de interrupção de GPIO exclusivo (não compartilhado).

• Lista o recurso de interrupção GPIO do botão de energia no objeto _AEI do controlador GPIO ao qual está conectado.

• Fornece o método de evento associado (Lxx/Exx/EVT) sob o dispositivo do controlador GPIO. Esse método de evento notifica o driver do Botão de Método de Controle no sistema operacional de que ocorreu o evento do botão.

Para obter mais informações, consulte botões de hardware para tablets e dispositivos conversíveis do Windows 8.

Matriz de botões compatível com Windows

Para plataformas prioritariamente ao toque (sem teclado), como tablets, o Windows fornece um driver genérico para cinco botões. Cada botão na matriz tem sua função definida (veja os itens numerados na lista abaixo) e determinadas combinações de botões "segurar e pressionar" têm um significado adicional na interface do usuário. Nenhuma combinação de botão é definida que exija que o botão de energia seja mantido pressionado. Para compatibilidade com o driver de botão de caixa de entrada do Windows, o dispositivo ACPI da Matriz de Botões compatível com Windows é implementado. O dispositivo é definido da seguinte maneira:

• Cada um dos cinco botões está conectado ao seu próprio pino de interrupção dedicado na plataforma.

• Cada pino de interrupção é configurado como um recurso de interrupção não compartilhado (Exclusivo), sensível a borda (Edge) que interrompe em ambas as bordas (Ativo em ambas).

• O namespace do dispositivo contém um _HID definido pelo fornecedor, bem como um _CID de PNP0C40.

• Os recursos de interrupção do GPIO no objeto _CRS são listados na seguinte ordem:

  1. Interrupção correspondente ao botão "Power"

     O botão "Energia" deve ser capaz de ativar o dispositivo (ExclusiveAndWake).

  2. Interrupção correspondente ao botão "Windows"

     O botão do Windows deve ser capaz de ativação (ExclusiveAndWake).

  3. Interrupção correspondente ao botão "Aumentar Volume"

     O botão "Aumento de Volume" não deve ser compatível com a ativação (deve usar Exclusive).

  4. Interrupção correspondente ao botão "Volume Diminuir"

     O botão "Volume Para Baixo" não deve ser capaz de acordar o dispositivo (deve usar o modo Exclusivo).

  5. Interruptor correspondente ao botão "Bloqueio de Rotação", se houver suporte

     O botão "Bloqueio de Rotação" não pode ser capaz de ativar o dispositivo (deve usar Exclusive).

Para obter mais informações, consulte botões de hardware para tablets e dispositivos conversíveis do Windows 8.

Para dar suporte à evolução da interface do usuário do Botão do Windows, o Windows define um método Device-Specific (_DSM) para o dispositivo Windows Button Array. Para obter mais informações, consulte o Método de Device-Specific da Matriz de Botões do Windows (_DSM).

Dispositivos de detecção para dock e PCs conversíveis

O Windows suporta docks e conversíveis (combinações clamshell/tablet) pelo uso de dois sensores no namespace ACPI. Esses dispositivos são compatíveis com o driver de botão de caixa de entrada do Windows. Observe que os mesmos requisitos que se aplicam ao dispositivo matriz de botões também se aplicam a esses dispositivos:

• As interrupções do GPIO ActiveBoth devem ser conectadas a um controlador GPIO integrado ao SoC (não a um controlador GPIO conectado a SPB).

• O controlador GPIO deve dar suporte a interrupções no modo de nível e reprogramação dinâmica de polaridade.

• O driver do controlador GPIO deve usar a emulação ActiveBoth fornecida pela extensão da estrutura GPIO (GpioClx).

• Se o estado declarado ("Encaixado" ou "Convertido") não for de nível lógico baixo, o método _DSM do controlador GPIO é necessário para substituir o comportamento padrão da pilha de driver GPIO. Para obter mais informações, consulte a seção de dispositivos do controlador GPIO no tópico de E/S de uso geral (GPIO ).

Para obter mais informações, consulte botões de hardware para tablets e dispositivos conversíveis do Windows 8.

Dispositivo de detecção de encaixe

Um dispositivo de detecção de encaixe interrompe o sistema quando um dock é anexado ou desanexado do sistema. Essas informações de alteração de modo são usadas para atualizar a experiência de entrada e saída do usuário, conforme necessário. O namespace do dispositivo requer:

• Um _HID específico do fornecedor

• Um _CID de PNP0C70

• Um _CRS com uma interrupção do ActiveBoth

  A interrupção não pode ser compatível com a ativação.

Dispositivo de detecção de COMPUTADOR conversível

Um dispositivo de detecção de PC conversível interrompe o sistema quando um computador conversível alterna de tablet para formato concha. Essas informações de alteração de modo são usadas para atualizar a experiência de entrada e saída do usuário, conforme necessário. O namespace do dispositivo requer:

• Um _HID específico do fornecedor

• Um _CID de PNP0C60

• Um _CRS com uma interrupção do ActiveBoth

  A interrupção não pode ser compatível com a ativação.