Objetos de namespace de gerenciamento de dispositivo

A especificação ACPI 5.0 define vários tipos de objetos de namespace que podem ser usados para gerenciar dispositivos. Por exemplo, os objetos de identificação do dispositivo contêm informações de identificação para dispositivos que se conectam a barramentos, como I2C, que não dão suporte à enumeração de hardware de dispositivos filho. Outros tipos de objetos de namespace podem especificar recursos do sistema, descrever dependências do dispositivo e indicar quais dispositivos podem ser desabilitados.

Identificação do dispositivo no Windows

O Windows Plug and Play localiza e carrega drivers de dispositivo com base em um identificador de dispositivo fornecido pelo enumerador do dispositivo. Os enumeradores são motoristas de ônibus que sabem como extrair informações de identificação do dispositivo. Alguns barramentos (como PCI, SD e USB) têm mecanismos definidos por hardware para fazer essa extração. Para barramentos que não dispõem de objetos de identificação (como o barramento do processador ou um barramento periférico simples), a ACPI define esses objetos no namespace.

O driver ACPI do Windows, Acpi.sys, reúne os valores encontrados nesses objetos em várias cadeias de caracteres de identificador de dispositivo que podem identificar um dispositivo especificamente ou genericamente, dependendo das necessidades do driver. Alguns dos padrões de cadeia de caracteres criados para identificar dispositivos enumerados por ACPI são:

ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd&SUBSYS_sss[s]nnnn
ACPI\VEN_vvv[v]&DEV_dddd&REV_rrrr
ACPI\VEN_vvv[v]&DEV_dddd
ACPI\vvv[v]dddd

Você pode ver os identificadores de dispositivo que o Windows cria para seu dispositivo abrindo o Gerenciador de Dispositivos e inspecionando as propriedades de IDs de hardware e IDs compatíveis do dispositivo enumerado. Cada uma dessas cadeias de caracteres está disponível para ser especificada em um arquivo INF para identificar o driver a ser carregado para o dispositivo. A ordem de correspondência INF é do identificador de hardware mais específico (driver mais preferido) ao identificador menos específico (driver menos preferido), permitindo que drivers que conhecem melhor os recursos específicos do dispositivo possam substituir os menos especializados (e, portanto, que dão suporte apenas a um subconjunto dos recursos do dispositivo).

Os identificadores de dispositivo devem ser usados apenas para correspondência INF e nunca devem ser analisados ou processados pelo driver do dispositivo. Se o driver do dispositivo tiver a necessidade de identificar o hardware específico para o qual foi carregado, o método recomendado é que o arquivo INF defina as chaves do Registro apropriadas no momento da instalação. O driver pode acessar essas chaves durante a inicialização para obter as informações necessárias.

Identificação do dispositivo no ACPI

ID de hardware (_HID)

O requisito mínimo para identificar um dispositivo no ACPI é o objeto ID de Hardware (_HID). _HID retorna uma cadeia de caracteres com o formato "ABC[D]xxxx", em que "ABC[D]" é uma cadeia de caracteres de 3 ou 4 caracteres que identifica o fabricante do dispositivo (a "ID do fornecedor"), e xxxx é um número hexadecimal que identifica o dispositivo específico fabricado por esse fornecedor (a "ID do dispositivo"). As IDs do fornecedor devem ser exclusivas em todo o setor. A Microsoft aloca essas cadeias de caracteres para garantir que elas sejam exclusivas. As IDs do fornecedor podem ser obtidas de Solicitação de ID Plug and Play - PNPID.

O ACPI 5.0 também dá suporte ao uso de IDs de fornecedor atribuídas por PCI em _HID e outros objetos de identificação, portanto, talvez você não precise obter uma ID do fornecedor da Microsoft. Para obter mais informações sobre os requisitos de identificação de hardware, consulte a seção 6.1.5, "_HID (ID de hardware)", da especificação ACPI 5.0.

ID compatível (_CID)

A Microsoft reservou a ID do fornecedor "PNP" para dispositivos compatíveis com drivers de caixa de entrada fornecidos com o Windows. O Windows define uma série de IDs de dispositivo para uso com essa ID do fornecedor que podem ser usadas para carregar o driver fornecido pelo Windows para um dispositivo. Um objeto separado, o objeto Compatible ID (_CID), é usado para retornar esses identificadores. O Windows sempre prefere IDs de hardware (retornados por _HID) em vez de IDs compatíveis (retornados por _CID) na correspondência INF e na seleção do driver. Essa preferência permite que o driver fornecido pelo Windows seja tratado como um driver padrão se um driver específico do dispositivo fornecido pelo fornecedor não estiver disponível. As IDs compatíveis na tabela a seguir são criadas recentemente para uso com plataformas SoC.

ID do subsistema (_SUB), Revisão de Hardware (_HRV) e Classe (_CLS)

O ACPI 5.0 define os objetos _SUB, _HRV e _CLS que podem ser usados junto com o _HID para criar identificadores que identifiquem de forma mais exclusiva uma versão, integração ou revisão de hardware específica de um dispositivo ou para indicar a associação em uma classe de dispositivo definida por PCI. Esses objetos geralmente são opcionais, mas podem ser exigidos por determinadas classes de dispositivo no Windows. Para obter mais informações sobre esses objetos, consulte a seção 6.1, "Objetos de Identificação do Dispositivo", da especificação ACPI 5.0.

Para a manutenibilidade, há um requisito do Kit de Certificação de Hardware do Windows (HCK) de que as IDs de dispositivo em sistemas OEM devam ser no formato de "quatro partes". As quatro partes são a ID do fornecedor, a ID do dispositivo, a ID do fornecedor do subsistema (OEM) e a ID do dispositivo OEM (subsistema). Portanto, o objeto de ID do subsistema (_SUB) é necessário para plataformas OEM.

Método Device-Specific (_DSM)

O método _DSM é definido na seção 9.14.1, "_DSM (Método Específico do Dispositivo)", da especificação ACPI 5.0. Esse método fornece funções de controle e dados individuais específicas do dispositivo que podem ser chamadas por um driver de dispositivo sem entrar em conflito com outros métodos específicos do dispositivo. O _DSM para um determinado dispositivo ou classe de dispositivo define um GUID (UUID) que tem a garantia de não entrar em conflito com outros UUIDs. Para cada UUID, há um conjunto de funções definidas que o método _DSM pode implementar para fornecer dados ou executar funções de controle para o driver. Os formatos de dados e dados específicos de classe são fornecidos em especificações específicas de classe de dispositivo separadas e também são discutidos nos Métodos ACPI Device-Specific.

Endereço (_ADR) e ID Exclusivo (_UID)

Há três requisitos adicionais para identificação do dispositivo:

• Para dispositivos que se conectam a um barramento pai enumerável por hardware (como SDIO, USB HSIC), mas que têm características ou controles específicos da plataforma (como alimentação via canal lateral ou interrupção de ativação), o _HID não é usado. Em vez disso, o identificador do dispositivo é criado pelo motorista do ônibus pai (conforme discutido anteriormente). Nesse caso, porém, o objeto Address (_ADR) é necessário para estar no namespace ACPI do dispositivo. Esse objeto permite que o sistema operacional associe o dispositivo enumerado por barramento a seus recursos ou controles descritos por ACPI.
• Em plataformas em que várias instâncias de um bloco IP específico são usadas, para que cada bloco tenha os mesmos objetos de identificação do dispositivo, o objeto Identificador Exclusivo (_UID) é necessário para permitir que o sistema operacional distingue entre blocos.
• Nenhum dispositivo em um escopo de namespace específico pode ter o mesmo nome.

Objetos de configuração do dispositivo

Para cada dispositivo identificado no namespace, os recursos do sistema (endereços de memória, interrupções e assim por diante) consumidos pelo dispositivo também devem ser relatados pelo objeto Configurações de Recurso Atuais (_CRS). Há suporte para o relato de múltiplas configurações de recursos possíveis (_PRS) e para controles que permitem alterar a configuração de recursos (_SRS) de um dispositivo, sendo ambos opcionais.

Novidades para plataformas SoC são recursos de GPIO e SPB (barramento periférico simples) que um dispositivo pode consumir. Para obter mais informações, consulte GPIO (E/S) de Uso Geral e SPB (Barramento Periférico Simples).

Também é novo para plataformas SoC um descritor de DMA fixo de uso geral. O descritor FixedDMA dá suporte ao compartilhamento de hardware do controlador de DMA por vários dispositivos do sistema. Os recursos de DMA (registros de linha de solicitação e canal) alocados estaticamente para um determinado dispositivo do sistema são listados no descritor FixedDMA. Para obter mais informações, consulte a seção 19.5.49, "FixedDMA (DMA Resource Descriptor Macro)", da especificação ACPI 5.0.

Alterações de status do dispositivo

Dispositivos enumerados por ACPI podem ser desabilitados ou removidos por vários motivos. O objeto Status (_STA) é fornecido para permitir que essas alterações de status sejam comunicadas ao sistema operacional. Para obter uma descrição de _STA, consulte a seção 6.3.7 da especificação ACPI 5.0. O Windows usa _STA para determinar se o dispositivo deve ser enumerado, mostrado como desabilitado ou não visível para o usuário. Esse controle no firmware é útil para muitas aplicações, incluindo o acoplamento e a alternância de host para função no modo OTG USB.

Além disso, a ACPI fornece um mecanismo de notificação que o ASL pode usar para notificar drivers de eventos na plataforma, como um dispositivo sendo removido como parte de um dock. Em geral, quando o status de um dispositivo ACPI é alterado, o firmware deve executar uma notificação de "verificação de dispositivo" ou "verificação de barramento" para fazer com que o Windows reenume o dispositivo e reavalie seu _STA. Para obter informações sobre notificações de ACPI, consulte a seção 5.6.6, "Notificações de objeto do dispositivo", da especificação ACPI 5.0.

Habilitar/desabilitar

Como parte do Windows Plug and Play, os drivers devem ser capazes de serem habilitados e desabilitados dinamicamente pelo usuário ou pelo sistema (por exemplo, para atualizar um driver).

Os dispositivos On-SoC são integrados ao chip SoC e não podem ser removidos. Os drivers para a maioria dos dispositivos on-SoC podem ser isentos dos requisitos para habilitar e desabilitar. Para os drivers que não são isentos, há interfaces de driver para indicar que o driver dá suporte à remoção ordenada. Para obter mais informações, consulte o documento intitulado "Reduzindo os requisitos de PNP para drivers SoC" no site do Microsoft Connect.

Se um driver der suporte à remoção ordenada e o hardware do dispositivo puder ser desabilitado (ou seja, o dispositivo pode ser configurado para parar de acessar seus recursos atribuídos), o nó de namespace ACPI para o dispositivo poderá incluir o objeto Desabilitar (_DIS). Esse método será avaliado pelo sistema operacional sempre que o driver for removido. O uso de _DIS tem os seguintes requisitos adicionais:

• _STA deve limpar o bit "habilitado e decodificar seus recursos" sempre que o dispositivo estiver desabilitado.
• O dispositivo deve fornecer o objeto Definir Configurações de Recurso (_SRS) para reabilitar o hardware do dispositivo e ajustar o bit mencionado acima em _STA.

Para obter mais informações, consulte as seções 6.2.3 (_DIS), 6.2.15 (_SRS) e 6.3.7 (_STA) da especificação ACPI 5.0.

Dependências do dispositivo

Normalmente, há dependências de hardware entre dispositivos em uma plataforma específica. O Windows requer que todas essas dependências sejam descritas para garantir que todos os dispositivos funcionem corretamente à medida que as coisas mudam dinamicamente no sistema (a energia do dispositivo é removida, os drivers são interrompidos e iniciados e assim por diante). No ACPI, as dependências entre dispositivos são descritas das seguintes maneiras:

1. Hierarquia de namespace. Qualquer dispositivo que seja um dispositivo filho (listado como um dispositivo dentro do namespace de outro dispositivo) depende do dispositivo pai. Por exemplo, um dispositivo USB HSIC depende da porta (pai) e do controlador (avô) ao qual ele está conectado. Da mesma forma, um dispositivo GPU listado no namespace de um dispositivo MMU (unidade de gerenciamento de memória do sistema) depende do dispositivo MMU.

2. Conexões de recurso. Os dispositivos conectados a controladores GPIO ou SPB dependem desses controladores. Esse tipo de dependência é descrito pela inclusão de Recursos de Conexão no _CRS do dispositivo.

3. Dependências OpRegion. Para métodos de controle ASL que usam OpRegions para executar E/S, as dependências não são implicitamente conhecidas pelo sistema operacional porque são determinadas apenas durante a avaliação do método de controle. Esse problema é aplicável às OpRegions GeneralPurposeIO e GenericSerialBus nas quais os drivers Plug and Play fornecem acesso à região. Para mitigar esse problema, o ACPI define o objeto de Dependência do OpRegion (_DEP). _DEP deve ser usado em qualquer namespace de dispositivo no qual uma OpRegion (recurso HW) é referenciada por um método de controle e nem 1 ou 2 acima já se aplica ao recurso de conexão do OpRegion referenciado. Para obter mais informações, consulte a seção 6.5.8, "_DEP (Dependências da Região da Operação)", da especificação ACPI 5.0.

Podem também haver dependências de software entre drivers de dispositivo. Essas dependências também devem ser descritas.

Para obter mais informações, consulte os seguintes recursos:

• Para dependências de ordem de carregamento do driver, consulte Especificando a ordem de carregamento do driver.

• Para dependências de relações de poder, consulte:

  • IoInvalidateDeviceRelations (para disparar o estabelecimento de relações de energia, chame a rotina IoInvalidateDeviceRelations com o valor de enumeração DEVICE_RELATION_TYPEPowerRelations.)

  • IRP_MN_QUERY_DEVICE_RELATIONS

  • WdfDeviceInitSetPnpPowerEventCallbacks

  • Enumerando os dispositivos em um barramento

  • Enumeração dinâmica