Outros objetos de namespace ACPI

Para algumas classes específicas de dispositivo, há requisitos para que objetos de namespace ACPI (Advanced Configuration and Power Interface) adicionais apareçam sob esses 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 "Dispositivo", como acontece com outros dispositivos na plataforma. Os dispositivos do processador devem conter os seguintes objetos:

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

Objetos específicos do ecrã

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

Display-Specific Requisitos do objeto

Controladores e dispositivos host USB

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

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

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

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

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

• As Configurações de Recursos Atuais (_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 USB Device-Specific (_DSM)

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

Suporte a conversor de transações (TT) integrado USB (_HRV)

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

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

• NoIntegratedTT - _HRV = 0

  Os controladores host EHCI padrão não implementam conversores de transações integrados, e um valor _HRV de 0 só é válido para esses controladores. Não é necessário incluir o objeto _HRV para esses controladores.

• IntegradoTTSpeedInPortSc - _HRV = 1

  Habilite o suporte TT integrado. Este tipo de interface inclui os bits LowSpeed e HiSpeed no próprio registo 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. Este tipo de interface inclui os bits LowSpeed e HiSpeed num registo HOSTPC separado. Quando o driver EHCI precisa determinar a velocidade da porta, ele lerá o registro HOSTPC correspondente à porta de interesse e extrairá as informações de velocidade.

Suporte para USB XHCI D3cold

Além da suspensão seletiva, os dispositivos USB internos conectados aos controladores XHCI podem ser colocados em um estado D3cold (estado de economia de energia profundo) e desativados 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 a 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, Physical Device Location (_PLD) e USB Port Capabilities (_UPC), são usados para essa finalidade. Para obter mais informações, consulte o seguinte:

• Seções 6.1.6, "Objetos de identificação de dispositivo", e 9.13.1, "Controladores host USB 2.0 e _UPC e _PLD", na especificação ACPI 5.0.

• Usando ACPI para configurar portas USB em um computador.

Controladores e dispositivos host SD

Os controladores host SD são usados em plataformas SoC para acesso ao armazenamento, bem como dispositivos de E/S. O Windows inclui um driver de caixa de entrada para hardware de controlador host padrão SDA. Para compatibilidade com este driver, um dispositivo SD Host Controller deve estar em conformidade com a especificação SD Host Controller da SD Association.

Em plataformas SoC, o controlador 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 (_HID) compatível com ACPI atribuída pelo fornecedor.

• Um objeto Unique ID (_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 host SD (PNP0D40) compatível com o padrão SDA.

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

  • Recursos de hardware para todos os slots implementados estão disponíveis. Um slot é um ponto de conexão no barramento SDIO para um dispositivo de memória ou E/S. Cada slot está associado a um conjunto padrão de registos e uma interrupção no controlador host SD, que são usados para a 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 do slot são listados juntos, em ordem de número do 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 SD definido para o slot.

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

    • Um recurso de interrupção GPIO para o slot, para sinalizar inserções e remoções de cartões (se a interface padrão de deteção de cartões SD não for suportada durante todos os estados de alimentação).

    • Um recurso de entrada GPIO para o slot para ler se um cartão está atualmente no slot (se a interface padrão de deteção de cartão SD não for suportada durante todos os estados de energia). Usa o mesmo pino associado à interrupção de inserção/remoção.

    • Um segundo recurso de entrada GPIO para verificar se o cartão no slot está protegido contra gravação (caso a interface padrão de proteção contra gravação do SD não seja compatível em todos os estados de energia).

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

Dispositivos SD incorporados

Dispositivos conectados via SD são enumerados pelo controlador de barramento SD. Os dispositivos SD integrados à plataforma também devem ser listados no namespace ACPI como filhos do controlador host SD. Este 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, não removibilidade, estados de energia do dispositivo, recursos GPIO ou SPB consumidos 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 deste inteiro é definido da seguinte forma:

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

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

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

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

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

Dispositivos de classe de imagem (câmaras)

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 com direção fixada mecanicamente são incluídos no namespace ACPI e fornecem o objeto Physical Device Location (_PLD). Para tal, é necessário:

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

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

  • Para USB, consulte Hierarquia de namespace ACPI e _ADR para dispositivos USB incorporados na próxima seção abaixo.

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

• O dispositivo de câmera para fornecer o objeto _PLD.

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

No objeto _PLD, os campos Painel (bits 67-69), Tampa (bit 66) e Dock (bit 65) são definidos com os 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 é o que segura a tela de exibição, e sua origem está no canto inferior esquerdo quando a tela é visualizada na orientação retrato. Usando esta referência, "Front" indica que a câmara está virada para o utilizador (webcam), enquanto "Back" indica que a câmara está virada para longe do utilizador (câmara fotográfica ou de vídeo). Para obter mais informações, consulte a seção 6.1.8, "_PLD (Localização física do dispositivo)", na especificação ACPI 5.0.

Hierarquia e _ADR de namespace ACPI para dispositivos USB incorporados

Ao adicionar dispositivos USB incorporados ao namespace ACPI, a hierarquia dos nós de dispositivo deve corresponder exatamente à dos dispositivos enumerados pelo driver USB do Windows. Isso pode ser determinado examinando o Gerenciador de dispositivos do Windows em seu modo "Exibir por conexão". Toda a hierarquia, começando pelo controlador host USB e estendendo-se até o dispositivo incorporado, deve ser incluída. A propriedade "Endereço" 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 forma:

USB Root HUB: Filho exclusivo do controlador host. Deve ter um _ADR de 0. Não são permitidas outras crianças ou valores de _ADR.

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

Os dispositivos USB ligados a uma porta específica partilham o endereço dessa porta.

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

Função USB dentro de um dispositivo USB composto: Número 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 Identificando a localização de câmeras internas.

Exemplos de código ASL

O exemplo de código ASL a seguir descreve uma webcam USB 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 sobre I2C

O Windows inclui um driver de classe para dispositivos de interface humana (HID). Este 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 são 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

• Uma _CID de PNP0C50

• Uma _CRS com:

  • Um recurso I2CSerialBusConnection para acesso ao dispositivo

  • Um recurso GpioInt para interrupção(ões)

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

Dispositivos de botão

Para plataformas SoC, o Windows suporta tanto o botão de energia definido pelo método de controle da ACPI, como uma disposição de cinco botões compatível com o Windows. O botão de alimentação, seja implementado como um Botão de Alimentação do Método de Controlo ACPI ou como parte do conjunto de botões compatíveis com o Windows, faz o seguinte:

• Faz com que a plataforma seja ativada se estiver desligada.

• Gera o evento Power Button Override quando pressionado. Para obter mais informações, consulte a secção 4.8.2.2.1.3, "Substituição do botão liga/desliga", da especificação ACPI 5.0.

Botão de controlo de energia

Os designs de tipo concha e outros sistemas com teclados integrados ou conectados implementam o Botão de Energia do Método de Controle definido pela ACPI (seção 4.8.2.2.1.2 da especificação ACPI 5.0) usando Eventos ACPI GPIO-Signaled (seção 5.6.5 da especificação ACPI 5.0). Para suportar o dispositivo do botão de ligar/desligar, o namespace:

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

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

• Fornece o método de evento associado (Lxx/Exx/EVT) no dispositivo controlador GPIO. Esse método de evento notifica o driver Control Method Button no sistema operacional que o evento button ocorreu.

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

Matriz de botões compatível com Windows

Para plataformas orientadas para toque (sem teclado), como tablets, o Windows fornece um driver genérico para uma matriz de cinco botões. Cada botão na matriz tem sua função definida (veja os itens numerados na lista abaixo), e certas combinações de botões "segure e pressione" têm significado adicional na interface do usuário. Não são definidas combinações de botões que exijam que o botão liga/desliga seja pressionado. Para compatibilidade com o driver de botão da caixa de entrada do Windows, o dispositivo ACPI Button Array compatível com Windows é implementado. O dispositivo é definido da seguinte forma:

• Cada um dos cinco botões está ligado 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), acionado por borda (Borda) que interrompe em ambas as bordas (ActiveBoth).

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

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

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

     O botão "Power" deve ser capaz de despertar (ExclusiveAndWake).

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

     O botão do Windows deve ser compatível com despertar (ExclusiveAndWake).

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

     O botão "Aumentar volume" não deve ativar (deve utilizar a função Exclusiva).

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

     O botão "Diminuir volume" não deve ser compatível com despertar (deve usar Exclusivo).

  5. Interrupção correspondente ao botão "Bloqueio de rotação", se suportado

     O botão "Bloqueio de rotação" não deve ser compatível com a ativação (deve usar Exclusivo).

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

Para suportar a evolução da interface do botão do Windows, o Windows define um método Device-Specific (_DSM) para o dispositivo Windows Button Array. Para mais informações, consulte Matriz de botões do Windows Método Device-Specific (_DSM).

Dock e dispositivos de deteção de PC conversíveis

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

• GPIO ActiveAmbas as interrupções devem ser conectadas a um controlador GPIO on-SoC (não a um controlador GPIO conectado ao SPB).

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

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

• Se o estado declarado ("Docked" ou "Converted") não atingir o nível lógico baixo, será necessário que o método _DSM do controlador GPIO substitua o comportamento padrão da pilha de drivers GPIO. Para obter mais informações, consulte a seção Dispositivos do controlador GPIO no tópico E/S de uso geral (GPIO).

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

Dispositivo de deteção da doca

Um dispositivo de deteção de doca interrompe o sistema quando uma estação de ancoragem é conectada ou desconectada 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

• Uma _CID de PNP0C70

• Um _CRS com uma interrupção ActiveBoth

  A interrupção não pode ser capaz de acordar o sistema.

Dispositivo de deteção de PC conversível

Um dispositivo de deteção de PC conversível interrompe o sistema quando um PC conversível muda de tablet para modo portátil (clamshell). 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

• Uma _CID de PNP0C60

• Um _CRS com uma interrupção ActiveBoth

  A interrupção não pode ser capaz de acordar o sistema.