Partilhar via

Objetos de namespace de gerenciamento de dispositivos

  • Artigo

A especificação ACPI 5.0 define vários tipos de objetos de namespace que podem ser usados para gerenciar dispositivos. Por exemplo, 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 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 são (como o barramento do processador ou um barramento periférico simples), o 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 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 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 de INF é do identificador de hardware mais específico (driver preferencial) ao identificador menos específico (driver menos preferencial), para que os drivers que sabem mais sobre os recursos específicos do dispositivo possam substituir aqueles que são menos específicos (e, portanto, dar 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 é fazer com que o arquivo INF defina as chaves do Registro apropriadas no momento da instalação. Em seguida, 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 de 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 Plug and Play ID – Solicitação 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 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 a ID do fornecedor "PNP" para dispositivos compatíveis com drivers de caixa de entrada enviados com o Windows. O Windows define várias 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 ID compatível (_CID), é usado para retornar esses identificadores. O Windows sempre prefere IDs de hardware (retornadas por _HID) em vez de IDs compatíveis (retornadas por _CID) na correspondência do 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 compatível Descrição
PNP0C40 Matriz de botões compatível com Windows
PNP0C50 Dispositivo compatível com HID-over-I2C
PNP0C60 Dispositivo de sensor de exibição laptop conversível
PNP0C70 Dispositivo de sensor de encaixe
PNP0D10 Controlador USB compatível com XHCI com depuração padrão
PNP0D15 Controlador USB compatível com XHCI sem depuração padrão
PNP0D20 Controlador USB compatível com EHCI sem depuração padrão
PNP0D25 Controlador USB compatível com EHCI com depuração padrão
PNP0D40 Controlador de host SD em conformidade com o padrão do SDA
PNP0D80 Controlador de gerenciamento de energia do sistema compatível com Windows

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 identificam 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 capacidade de serviço, há um requisito do HCK (Kit de Certificação de Hardware) do Windows para 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 OEM (subsistema). Portanto, o objeto 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 da classe são fornecidos em especificações específicas da classe de dispositivo separadas e também são discutidos em Métodos de Device-Specific do ACPI.

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

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

  • Para dispositivos que se conectam a um barramento pai enumerável por hardware (por exemplo, SDIO, USB HSIC), mas que têm recursos ou controles específicos da plataforma (por exemplo, sideband ou interrupção de ativação), o _HID não é usado. Em vez disso, o identificador do dispositivo é criado pelo motorista do barramento pai (conforme discutido anteriormente). Nesse caso, porém, o Objeto address (_ADR) é necessário 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 Recursos Atuais (_CRS). Há suporte para relatórios de várias configurações de recursos possíveis (_PRS) e controles para alterar a configuração de recursos de um dispositivo (_SRS), mas opcional.

Novidades para plataformas SoC são gpio e SPB (barramento periférico simples) que um dispositivo pode consumir. Para obter mais informações, consulte Uso Geral GPIO (E/S) 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

Os 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 muitos aplicativos, incluindo encaixe e alternância de host para função 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 renumere o dispositivo e reavalie seus _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 ser habilitados dinamicamente e desabilitados 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 no 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 poderá 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 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 exige que todas essas dependências sejam descritas para que 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). 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 recursos. 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 a GeneralPurposeIO e GenericSerialBus OpRegions em que Plug and Play drivers fornecem acesso à região. Para atenuar esse problema, o 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 nenhum 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.

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

Para saber mais, consulte os recursos a seguir: