Objetos de namespace de gerenciamento de dispositivos

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 de dispositivo contêm informações de identificação para dispositivos que se conectam a barramentos, como I2C, que não oferecem suporte à enumeração de hardware de dispositivos filho. Outros tipos de objetos de namespace podem especificar recursos do sistema, descrever dependências de dispositivos 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. Enumeradores são controladores de barramento 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 o fazem (como o barramento do processador ou um barramento periférico simples), a ACPI define objetos de identificação 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 sequências de caracteres criados para identificar dispositivos enumerados 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 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) para o identificador menos específico (driver menos preferido), de modo que os drivers que sabem mais sobre os recursos específicos do dispositivo podem substituir aqueles que são menos específicos (e, portanto, suportam apenas 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 de dispositivo. Se o driver de dispositivo tiver a necessidade de identificar o hardware específico para o qual foi carregado, o método recomendado é ter o arquivo INF definir chaves de registro apropriadas no momento da instalação. O driver pode então acessar essas chaves durante a inicialização para obter as informações necessárias.

Identificação do dispositivo na ACPI

ID do hardware (_HID)

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

A ACPI 5.0 também suporta o 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 de 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 o ID de 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 de 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 seleção de 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 recém-criadas para uso com plataformas SoC.

Identificação do Subsistema (_SUB), Revisão de Hardware (_HRV) e Classe (_CLS)

A 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 específica, integração ou revisão de hardware de um dispositivo, ou para indicar a associação a 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 de dispositivo", da especificação ACPI 5.0.

Para facilitar a manutenção, há um requisito do Kit de Certificação de Hardware do Windows (HCK) de que as IDs de dispositivo em sistemas OEM sejam IDs 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 do subsistema (OEM). Portanto, o objeto ID do subsistema (_SUB) é necessário para plataformas OEM.

Método Device-Specific (_DSM)

O método _DSM é definido no ponto 9.14.1, "_DSM (Device Specific Method)", da especificação ACPI 5.0. Este método fornece dados individuais específicos do dispositivo e funções de controlo que podem ser chamadas por um controlador 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 UUID (GUID) que é garantido 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. Dados e formatos de dados específicos de classe são fornecidos em especificações separadas para classes específicas de dispositivos e também são discutidos em Métodos de ACPI Device-Specific.

Endereço (_ADR) e ID Único (_UID)

Existem três requisitos adicionais para a identificação do dispositivo:

• Para dispositivos que se conectam a um barramento principal enumerável por hardware (por exemplo, SDIO, USB HSIC), mas que possuem funcionalidades ou controles específicos da plataforma (por exemplo, alimentação auxiliar ou interrupção de ativação), o _HID não é utilizado. Em vez disso, o identificador de dispositivo é criado pelo driver de barramento pai (conforme discutido anteriormente). Nesse caso, porém, o objeto de endereço (_ADR) é necessário estar no namespace ACPI para o dispositivo. Este objeto permite que o sistema operacional associe o dispositivo enumerado por barramento com seus recursos ou controles descritos pela ACPI.
• Em plataformas onde várias instâncias de um determinado bloco IP são usadas, para que cada bloco tenha os mesmos objetos de identificação de dispositivo, o objeto Identificador Exclusivo (_UID) é necessário para permitir que o sistema operacional distinga 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 Current Resource Settings (_CRS). Relatórios de várias configurações de recursos possíveis (_PRS) e controles para alterar a configuração de recursos (_SRS) de um dispositivo são suportados, mas opcionais.

As novidades para plataformas SoC são o GPIO e os recursos de barramento periférico simples (SPB) que um dispositivo pode consumir. Para obter mais informações, consulte E/S de uso geral (GPIO) eBarramento periférico simples (SPB).

Outra novidade para plataformas SoC é um descritor DMA fixo de uso geral. O descritor FixedDMA suporta o compartilhamento de hardware do controlador DMA por vários dispositivos do sistema. Os recursos DMA (registradores de linha e canal de solicitação) alocados estaticamente para um dispositivo de sistema específico estã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 no estado do dispositivo

Os dispositivos enumerados ACPI podem ser desativados ou removidos por vários motivos. O objeto Status (_STA) é fornecido para permitir que tais alterações de status sejam comunicadas ao sistema operacional. Para uma descrição dos _STA, ver secção 6.3.7 da especificação ACPI 5.0. O Windows usa _STA para determinar se o dispositivo deve ser enumerado, mostrado como desativado ou não visível para o usuário. Este controlo no firmware é útil para muitas aplicações, incluindo ancoragem e comutação de anfitrião para função USB OTG.

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

Ativar/desativar

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

Os dispositivos On-SoC são integrados no chip SoC e não podem ser removidos. Os drivers para a maioria dos dispositivos SoC podem ser isentos dos requisitos para ativar e desativar. Para os controladores que não estão isentos, há interfaces de controlador para indicar que o controlador suporta a remoção ordenada. Para obter mais informações, consulte o documento intitulado "Reduzindo os requisitos PNP para drivers SoC" no site Microsoft Connect.

Se um driver suportar a remoção ordenada e o hardware do dispositivo puder ser desativado (ou seja, o dispositivo pode ser configurado para parar de acessar seus recursos atribuídos), o nó do namespace ACPI do dispositivo pode incluir o objeto Disable (_DIS). Este 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 "ativado e descodificando os seus recursos" sempre que o dispositivo estiver desligado.
• O dispositivo deve fornecer o objeto set Resource Settings (_SRS) para reativar o hardware do dispositivo e definir o bit 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 que ele possa 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). Na 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 HSIC USB depende da porta (pai) e do controlador (avô) ao qual 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 recursos. Os dispositivos conectados aos 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 elas só são determinadas durante a avaliação do método de controle. Esse problema é aplicável a GeneralPurposeIO e GenericSerialBus OpRegions nas quais os drivers Plug and Play fornecem acesso à região. Para atenuar esse problema, a ACPI define o objeto OpRegion Dependency (_DEP). _DEP deve ser usado em qualquer namespace de dispositivo no qual um OpRegion (recurso HW) é referenciado por um método de controle, e nem 1 nem 2 acima já se aplicam ao recurso de conexão OpRegion referenciado. Para obter mais informações, consulte a seção 6.5.8, "_DEP (Operation Region Dependencies)", da especificação ACPI 5.0.

Também pode 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 carga do driver, consulte Especificando a ordem de carga do driver.

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

  • IoInvalidateDeviceRelations (Para acionar o estabelecimento de relações de poder, chame a rotina IoInvalidateDeviceRelations com o valor enum DEVICE_RELATION_TYPEPowerRelations.)

  • IRP_MN_QUERY_DEVICE_RELATIONS

  • WdfDeviceInitSetPnpPowerEventCallbacks

  • A enumeração dos dispositivos em um barramento

  • Enumeração dinâmica