Outros objetos de namespace ACPI
Para algumas classes específicas do dispositivo, há requisitos para que objetos de namespace ACPI (Advanced Configuration and 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 processador devem conter os seguintes objetos:
- _HID: ACPI0007
- _UID: um número exclusivo que corresponde à entrada do processador no MADT.
Objetos específicos para 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
| Método | Descrição | Requisito |
|---|---|---|
| _DOS | Habilitar/desabilitar a alternância de saída. | Obrigatório se o sistema der suporte a alternância de tela ou níveis de brilho LCD. |
| _DOD | Enumerar todos os dispositivos anexados ao adaptador de exibição. | Necessário se o controlador integrado der suporte à alternância de saída. |
| _ROM | Obter dados rom. | Obrigatório se a imagem ROM estiver armazenada no formato proprietário. |
| _GPD | Obter dispositivo POST. | Obrigatório se _VPO for implementado. |
| _SPD | Defina o dispositivo POST. | Obrigatório se _VPO for implementado. |
| _VPO | Opções post de vídeo. | Obrigatório se o sistema der suporte à alteração do dispositivo pós-VGA. |
| _ADR | Retornar a ID exclusiva para este dispositivo. | Obrigatórios. |
| _BCL | Lista de consultas com suporte para níveis de controle de brilho. | Necessário se o LCD inserido der suporte ao controle de brilho. |
| _BCM | Defina o nível de brilho. | Obrigatório se _BCL for implementado. |
| _DDC | Retorne o EDID para este dispositivo. | Obrigatório se o LCD inserido não der suporte ao retorno de EDID por meio da interface padrão. |
| _DCS | Retornar status do dispositivo de saída. | Obrigatório se o sistema der suporte à alternância de exibição (via tecla de acesso). |
| _DGS | Estado de gráficos de consulta. | Obrigatório se o sistema der suporte à alternância de exibição (via tecla de acesso). |
| _DSS | Conjunto de estado do dispositivo. | Obrigatório se o sistema der suporte à alternância de exibição (via tecla de acesso). |
Dispositivos e controladores de host USB
Os controladores de host USB são usados em plataformas SoC para conectar dispositivos internos e externos. O Windows inclui drivers de caixa de entrada 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 por ACPI. O Windows usa os seguintes objetos de namespace ACPI ao enumerar e configurar um hardware USB compatível:
Uma ID de Hardware (_HID) compatível com ACPI atribuída pelo fornecedor.
Um objeto ID exclusiva (_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 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 Device-Specific USB (_DSM)
O Windows define um método de Device-Specific (_DSM) para dar suporte à configuração específica da classe de dispositivo do subsistema USB. Para obter mais informações, consulte Método de Device-Specific USB.
Suporte a TT (tradutor de transações integradas) usb (_HRV)
Os controladores de host EHCI Standard 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 revisão de hardware (_HRV) indica o tipo de suporte TT integrado ao driver do controlador de host USB.
A _HRV é definida de acordo com os seguintes critérios:
NoIntegratedTT - _HRV = 0
Os controladores de host EHCI padrão não implementam tradutores de transações integrados e um valor de _HRV de 0 só é válido para esses controladores. Não é necessário incluir o objeto _HRV para esses controladores.
IntegratedTTSpeedInPortSc - _HRV = 1
Habilite o suporte integrado ao TT. Esse tipo de interface inclui os bits LowSpeed e HiSpeed no próprio registro PORTSC. Esses bits estão em 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 integrado ao TT. 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 colocados em um 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 aceitar D3cold.
Objetos específicos da porta USB
O Windows precisa saber a visibilidade e a capacidade de conexão de portas USB no sistema. Isso é necessário para fornecer informações precisas ao usuário sobre portas e dispositivos. Dois objetos, Local do Dispositivo Físico (_PLD) e Recursos de Porta USB (_UPC), são usados para essa finalidade. Para saber mais, consulte o seguinte:
Seções 6.1.6, "Objetos de Identificação de Dispositivo" e 9.13.1, "Controladores de host USB 2.0 e _UPC e _PLD", na especificação ACPI 5.0.
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 de caixa de entrada para hardware do 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 por 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 ID exclusiva (_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 atuais (_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 memória ou de E/S. 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, para sinalização cartão inserções e remoções (se não houver suporte para a interface de detecção de cartão de SD padrão durante todos os estados de energia).
Um recurso de entrada GPIO para o slot para ler se um cartão está atualmente no slot (se não houver suporte para a interface de detecção de cartão SD padrão durante todos os estados de energia). Usa o mesmo pino que a interrupção de inserção/remoção.
Um segundo recurso de entrada GPIO para ler se o cartão no slot é protegido por gravação (se a interface de proteção de gravação do SD padrão não tiver suporte durante todos os estados de energia).
As interrupções devem ser compatíveis com a ativação (descritas como "SharedAndWake" ou "ExclusiveAndWake").
Dispositivos SD inseridos
Os dispositivos conectados a 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, não removabilidade, 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 desse inteiro é definido da seguinte maneira:
Palavra alta – número do slot (0 – primeiro slot)
Palavra baixa – número da função (consulte Especificação do SD para definições.)
Um namespace de dispositivo SD inserido também deve incluir:
Um objeto de método 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 classe 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 que são integrados ao chassi do sistema e 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 a ser exibido como um filho (dispositivo aninhado) do dispositivo enumerador (o dispositivo GPU ou o dispositivo USB).
O dispositivo de câmera para fornecer o objeto Address (_ADR) que contém o endereço da câmera no barramento do dispositivo pai.
Para USB, consulte Hierarquia de namespace 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.
O dispositivo de câmera para fornecer o objeto _PLD.
Se houver recursos de sideband exigidos pelo driver da câmera (como interrupção gpio ou 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 Lid (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 o vídeo é exibido na orientação retrato. Usando essa referência, "Front" indica que a câmera exibe o usuário (webcam), enquanto "Voltar" indica que a câmera é exibida para longe do usuário (câmera parada ou vídeo). Para obter mais informações, consulte, seção 6.1.8, "_PLD (Local Físico do Dispositivo)", na especificação ACPI 5.0.
Hierarquia de namespace 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 Windows Gerenciador de Dispositivos no modo "Exibir 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 em 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 apenas do controlador de host. 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 no dispositivo composto deverão usar o seguinte endereço:
Função USB em um dispositivo USB composto: número da porta à qual o dispositivo composto está conectado, MAIS o primeiro Número da interface da função. (Adição aritmética).
Para obter mais informações, consulte Identificando o local das 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-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 pelo 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 de _DSM HIDI2C para retornar o endereço de Registro do Descritor HID no dispositivo. Para obter mais informações, consulte 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 por ACPI, bem como a uma matriz de cinco botões compatível com Windows. O botão ligar/desligar, 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 habilitada se ela estiver desativada.
Gera o evento De substituição do botão de energia quando mantido inativo. Para obter mais informações, consulte a seção 4.8.2.2.1.3, "Substituição de botão de energia", da especificação ACPI 5.0.
Botão de energia do método de controle
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, o namespace:
Descreve o pino de interrupção GPIO do botão de energia como um recurso de interrupção gpio não compartilhado (exclusivo).
Lista o recurso de interrupção GPIO do botão de energia 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 do Botão de Método de Controle no sistema operacional de que o evento de botão ocorreu.
Para obter mais informações, consulte Botões de hardware para dispositivos Windows 8 tablet e conversíveis.
Matriz de botões compatível com Windows
Para plataformas touch-first (sem teclado), como slates, o Windows fornece um driver genérico para uma matriz de cinco botões. Cada botão na matriz tem sua função definida (consulte os itens numerados na lista abaixo) e determinadas combinações de botões "segurar e pressionar" têm 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 da caixa de entrada do Windows, o dispositivo ACPI de Matriz de Botões compatível com Windows é implementado. O dispositivo é definido da seguinte maneira:
Cada um dos cinco botões está conectado ao 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), disparado por borda (Edge) que interrompe ambas as bordas (ActiveBoth).
O namespace do dispositivo contém uma _HID definida pelo fornecedor, bem como uma _CID de PNP0C40.
Os recursos de interrupção do GPIO no objeto _CRS são listados na seguinte ordem:
Interrupção correspondente ao botão "Ligar/Desligar"
O botão "Power" deve ter capacidade de ativação (ExclusiveAndWake).
Interrupção correspondente ao botão "Windows"
O botão do Windows deve ter capacidade de ativação (ExclusiveAndWake).
Interrupção correspondente ao botão "Aumentar Volume"
O botão "Aumentar Volume" não deve ter capacidade de ativação (deve usar Exclusivo).
Interrupção correspondente ao botão "Diminuir volume"
O botão "Diminuir volume" não deve ter capacidade de ativação (deve usar Exclusivo).
Interrupção correspondente ao botão "Bloqueio de Rotação", se houver suporte
O botão "Bloqueio de Rotação" não deve ter capacidade de ativação (deve usar Exclusivo).
Para obter mais informações, consulte Botões de hardware para dispositivos Windows 8 tablet e conversíveis.
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 Matriz de Botões do Windows. Para obter mais informações, consulte Método de Device-Specific de matriz de botões do Windows (_DSM).
Encaixe e dispositivos de detecção de computador conversíveis
O Windows dá suporte a encaixes e conversíveis (combinações clamshell/tablet) pelo uso de dois dispositivos de detecção 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 no 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 de polaridade dinâmica.
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 declarado nível lógico baixo, o controlador GPIO _DSM método será necessário para substituir o comportamento padrão da pilha de driver gpio. Para obter mais informações, consulte a seção Dispositivos de controlador GPIO no tópico E/S de uso geral (GPIO ).
Para obter mais informações, consulte Botões de hardware para dispositivos Windows 8 tablet e conversíveis.
Dispositivo de detecção de encaixe
Um dispositivo de detecção de encaixe interrompe o sistema quando um encaixe é 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:
Uma _HID específica 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 conversível-pc-sensing interrompe o sistema quando um computador conversível alterna de tablet para fator de forma 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:
Uma _HID específica 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.