Requisitos de firmware para D3cold
Começando com Windows 8, os dispositivos podem inserir o sub-estado de energia D3cold mesmo quando o sistema permanece no estado de energia S0. Este tópico descreve os requisitos de firmware para implementar o suporte de D3cold para um dispositivo inserido. A discussão a seguir destina-se a ajudar os desenvolvedores de firmware a permitir que seus dispositivos inseridos insiram e saiam de forma confiável da D3cold.
Além disso, os requisitos do driver de dispositivo para dar suporte ao D3cold são brevemente discutidos. Para obter mais informações sobre o suporte ao driver de dispositivo para D3cold, consulte Suporte a D3cold em um driver.
Introdução
Os estados de energia do dispositivo são definidos na especificação acpi e em várias especificações de barramento. A especificação do barramento PCI, desde que introduziu o gerenciamento de energia PCI, dividiu o estado de energia do dispositivo D3 (desativado) em dois sub-estados, D3hot e D3cold. Essa distinção foi adicionada à especificação ACPI no ACPI 3.0 e estendida no ACPI 4.0. O Windows sempre deu suporte a sub-estados D3, mas o Windows 7 e versões anteriores do Windows dão suporte ao sub-estado D3cold somente quando todo o computador sai do estado de energia do sistema S0 (em funcionamento) para entrar em um estado de suspensão ou hibernação— geralmente S3 ou S4. Começando com Windows 8, os drivers de dispositivo podem permitir que seus dispositivos insiram o estado D3cold mesmo enquanto o sistema permanece no S0.
D3hot, que geralmente é chamado de "D3", é o estado "soft-off" do dispositivo. Nesse estado, o dispositivo pode ser detectado por uma verificação de barramento e os comandos enviados para o dispositivo podem fazer com que ele ligue novamente. Em D3cold, todas as fontes de energia são removidas, com a possível exceção de uma pequena quantidade de energia para conduzir a lógica de ativação do dispositivo. Por exemplo, para dispositivos PCI Express (PCIe), a fonte de alimentação do dispositivo main, Vcc, é frequentemente desativada em uma transição para D3cold. Desativar a Vcc pode reduzir o consumo de energia e estender o tempo que uma plataforma de hardware móvel pode executar com uma carga de bateria. Quando um dispositivo está em D3cold, ele não pode ser detectado por uma verificação de barramento e não pode receber comandos. A restauração da energia Vcc move o dispositivo para um estado não inicializado, que geralmente é equivalente ao estado D0. Em seguida, o software deve inicializar novamente o dispositivo para colocá-lo no estado de trabalho.
Colocar um dispositivo em D3cold não significa necessariamente que todas as fontes de energia para o dispositivo foram removidas— isso significa apenas que a fonte de energia main, Vcc, foi removida. A fonte de energia auxiliar, Vaux, também poderá ser removida se não for necessária para a lógica de ativação. No entanto, um dispositivo que pode ser necessário para sinalizar um evento de ativação para o processador deve ser capaz de extrair energia suficiente para operar a lógica de ativação. Por exemplo, uma NIC (interface de rede Ethernet cartão) cuja fonte de alimentação main é removida pode extrair energia suficiente do cabo Ethernet. Ou, a energia em espera para uma NIC Wi-Fi pode ser fornecida de uma fonte fora da interface PCIe, nesse caso, a interface PCIe pode ser completamente desativada.
Na discussão a seguir, um conjunto de requisitos é descrito para habilitar as transições de estado de energia do dispositivo para D3cold. Esses requisitos se enquadram nas duas categorias a seguir:
Requisitos de firmware e plataforma
Requisitos do driver de dispositivo
A primeira dessas duas categorias é o foco main desta discussão. Uma breve visão geral da segunda categoria é apresentada. Para obter mais informações sobre os requisitos do driver de dispositivo, consulte Suporte a D3cold em um Driver.
Requisitos de firmware e plataforma
Na discussão a seguir, os requisitos de firmware e plataforma para habilitar o D3cold são apresentados para esses dois casos:
Quando o dispositivo é enumerado no ACPI.
Quando o dispositivo é enumerado por seu barramento pai.
A maior parte da discussão a seguir é específica para PCIe. No entanto, os princípios gerais descritos aqui se aplicam em grande parte a outros ônibus também.
Abstraindo alguns detalhes, a transição de D3cold para D0 é disparada pela nova aplicação da energia Vcc ao dispositivo inserido. A nova aplicação de energia restaura efetivamente a conexão do dispositivo com o barramento. O Windows lê os identificadores do dispositivo para distinguir entre os dois casos a seguir:
Um dispositivo foi removido e substituído por outro dispositivo.
O mesmo dispositivo foi removido e reinserido.
Se os identificadores corresponderem, o driver do dispositivo reinicializará o dispositivo. Se os identificadores não corresponderem, o Windows descarregará o driver do dispositivo e criará uma nova pilha de driver para o novo dispositivo. PCIe, por exemplo, consulta a ID do fornecedor, a ID do dispositivo e as IDs do subsistema (que são divididas em IDs de subprojeto e subprocurador em algumas versões da especificação). Esses identificadores devem corresponder aos do dispositivo anexado anteriormente depois que a energia for aplicada novamente (e o período de espera especificado pelo barramento decorrido); caso contrário, o Windows considerará o novo dispositivo diferente do anterior.
Caso 1: um dispositivo inserido é enumerado no ACPI
Se um dispositivo inserido não for detectável por meio de mecanismos definidos por uma especificação de barramento, como PCIe ou USB, mas o dispositivo estiver permanentemente conectado (ou pelo menos a conexão for dedicada a um dispositivo conhecido), esse dispositivo poderá ser descrito no firmware da plataforma por objetos acPI _HID e/ou _CID. Esses objetos permitem que o dispositivo seja enumerado pelo OSPM. ("OSPM" é um termo definido na especificação acpi. Significa, vagamente, "software que não é firmware.") O OSPM enumera um dispositivo somente quando nenhum enumerador de barramento pode detectar a ID do dispositivo. Por exemplo, os dispositivos em um barramento ISA são enumerados pelo OSPM. Além disso, os dispositivos em um SoC (Sistema em um Chip) geralmente são enumerados pelo ACPI porque estão em malha não enumerável. Exemplos desses dispositivos incluem controladores de host USB e SD.
Firmware de plataforma (enumerado no ACPI)
O OSPM usa \_SB._OSC para transmitir recursos do OSPM em toda a plataforma para o firmware da plataforma. O firmware da plataforma deve definir o bit 2 no valor retornado \_SB._OSC para indicar ao OSPM que o dispositivo dá suporte a _PR3. Para obter mais informações, consulte a seção 6.2.10.2, "Platform-Wide OSPM Capabilities", na especificação ACPI 5.0.
Dispositivo inserido (descoberto somente por meio do ACPI)
Para dar suporte ao D3cold, o firmware da plataforma deve implementar os seguintes objetos de recurso de energia ACPI para o dispositivo inserido:
_PR0: esse objeto é avaliado como os requisitos de energia do dispositivo no estado de energia do dispositivo D0 (totalmente ativado). O valor retornado é a lista de recursos de energia que o dispositivo requer no estado D0.
_PR2: esse objeto é avaliado para os requisitos de energia do dispositivo no estado de energia do dispositivo D2. O valor retornado é a lista de recursos de energia que o dispositivo requer no estado D2. Observe que, por motivos históricos, o Windows espera que _PR2 estejam presentes sempre que _PR0 estiver presente. Se D2 for implementado no hardware, _PR2 listará os recursos de energia necessários para D2. Se D2 não for implementado, _PR2 listará os mesmos recursos que _PR0.
_PR3: esse objeto é avaliado para os requisitos de energia do dispositivo no estado de energia do dispositivo D3hot. O valor retornado é a lista de recursos de energia que o dispositivo requer no estado D3hot.
Para cada recurso de energia identificado em qualquer objeto _PRx, os seguintes métodos de controle devem ser implementados:
_OFF: defina o recurso de energia para o estado desativado (desligar o recurso).
_ON: defina o recurso de energia para o estado ativado (ligar o recurso).
_STA: esse objeto é avaliado como o estado atual ativado ou desativado do recurso de energia (0: desativado, 1: ativado).
Uma transição para D3cold ocorre quando o ACPI executa o método de controle _OFF nos recursos de energia listados em _PR3. Observe que, se o driver de função do dispositivo indicar suporte para D3cold, esse suporte não implica que todas as transições para D3 resultem em transições rápidas para D3cold. É possível que o dispositivo insira e permaneça em D3hot por um período estendido e, em seguida, retorne a D0 sem nunca inserir D3cold ou insira D3cold posteriormente.
Dispositivo pai (enumerado no ACPI)
Não há nenhum requisito para que um dispositivo pai seja capaz de ser gerenciado por energia. No entanto, se um dispositivo pai for gerenciado por energia, o Windows nunca desligará esse dispositivo se algum de seus filhos (dispositivos dependentes) não estiver em D3.
Exemplo (enumerado no ACPI)
O diagrama de bloco a seguir mostra um dispositivo inserido (rotulado como EMBD) em um barramento do sistema. A main energia (Vcc) e a potência auxiliar (Vaux) para o dispositivo podem ser ativadas e desativadas independentemente por meio da lógica do Power rotulada pelo bloco.
O exemplo de código ASL a seguir descreve os recursos de energia usados pelo dispositivo inserido no diagrama anterior. Este exemplo começa com uma declaração de um método de controle _OSC que descreve os recursos do driver do dispositivo. Em seguida, os dois recursos de energia do dispositivo são declarados: os nomes de recursos PVCC e PVAX são atribuídos às fontes de energia main e auxiliares do dispositivo, Vcc e Vaux. Por fim, os requisitos de recursos de energia são listados para cada estado de energia do dispositivo que o dispositivo dá suporte e os recursos de ativação do dispositivo são descritos.
Scope (\_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVCC,0,0) // Power resource representing the main power for the device.
// Required for the device to be fully functional (D0).
{
Name(_STA,VAR1) // Return the state of the power resource.
Method(_ON,0x0) {...} // Turn on the power resource and set VAR1 to 1.
Method(_OFF,0x0) {...} // Turn off the power resource and set VAR1 to 0.
}
PowerResource(PVAX,0,0) // Power resource representing the auxiliary power for the device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
Device(EMBD) // An ACPI-enumerated device on the processor bus that supports D3Cold
{
Name(_HID, ...)
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVCC, PVAX}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package() {PVCC, PVAX}) // If D2 is implemented in the hardware,
// list the power resources needed by D2.
// If D2 is not implemented, list the same
// resources as _PR3.
// Indicate support for D3Cold.
Name(_PR3, Package() {PVCC, PVAX}) // Power resource for D3. These will be
// turned off ONLY if drivers opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the device doesn't
// need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform is
// capable of handling wake events from this device while in S0.
// The value of this object indicates the lowest D-state this device
// can be in to trigger wake events that can be handled while the
// platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way for OSPM to
// enable and disable them. The mechanism for this depends on the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with either of the above, if wake enablement
// varies depending on the target S-state and D-state.
*/
} // End of Device EMBD
} End Scope \_SB
Caso 2: um dispositivo inserido é enumerado por barramento
Se o dispositivo inserido estiver em conformidade com uma especificação de barramento comum, como PCIe ou USB, esse dispositivo será detectável por meio de mecanismos definidos pelo barramento e a energia poderá ser fornecida parcial ou totalmente por meio do barramento. Se esse dispositivo não for alimentado por outros recursos de energia de sideband, a fonte de alimentação main do dispositivo será o link que conecta o dispositivo ao controlador de barramento pai. Os dispositivos enumerados no barramento podem ser identificados pelo objeto _ADR na definição do dispositivo inserido. Um objeto _ADR é usado para fornecer o OSPM com o endereço de um dispositivo no barramento pai do dispositivo inserido. Esse endereço é usado para vincular a representação do dispositivo do barramento (conforme visto pelo hardware do barramento) à representação da plataforma do dispositivo (conforme visto pelo firmware ACPI). (A codificação de endereço _ADR é específica do barramento. Para obter mais informações, consulte a seção 6.1.1, "_ADR (Endereço)", na especificação do ACPI 5.0.) Quando esse mecanismo é empregado, o suporte a D3cold deve ser coordenado com o motorista do ônibus pai.
Se o main fonte de alimentação de um dispositivo inserido for o link que conecta esse dispositivo ao barramento pai, o principal requisito para colocar o dispositivo em D3cold será desligar o link. Para obter mais informações sobre a transição para D3cold, consulte o grafo de estado em Estados de Energia do Dispositivo.
Firmware de plataforma (enumerado por barramento)
O OSPM usa \_SB._OSC para transmitir funcionalidades do OSPM em toda a plataforma para o firmware da plataforma. O firmware da plataforma deve definir o bit 2 no valor retornado \_SB._OSC para indicar ao OSPM que o dispositivo dá suporte a _PR3. Para obter mais informações, consulte a seção 6.2.10.2, "Platform-Wide OSPM Capabilities", na especificação ACPI 5.0.
Dispositivo inserido (enumerado por barramento)
Nenhuma alteração de ACPI específica de D3cold é necessária. Nesse caso, desde que o driver e a plataforma do dispositivo tenham indicado suporte para D3cold, o link do barramento que fornece energia para o dispositivo inserido pode ser desativado quando o barramento pai sai do D0 e entra em um Dx de estado de baixa potência. A transição do dispositivo inserido de D3hot para D3cold ocorre quando a energia é removida do link. O estado Dx que o barramento pai entra pode ser qualquer estado que fará com que a fonte de energia do link seja desativada.
Dispositivo pai (enumerado por barramento)
O descritor ACPI para o barramento pai deve fazer o seguinte:
Implemente _S0W(Dx). Esse objeto especifica Dx como o estado D de menor potência do qual o dispositivo filho (inserido) pode ser ativado quando o sistema está no estado S0.
Defina recursos de energia para representar o link que conecta o dispositivo filho (inserido) ao barramento pai. Além disso, _ON, _OFF e objetos _STA devem ser definidos para esse recurso de energia. O exemplo de código ASL que segue esta lista descreve a potência do link como dois recursos, PVC1 e PVX1. Para cada um desses recursos, _ON, _OFF e objetos _STA são definidos.
Se "Dx" (o estado D de menor potência; consulte o primeiro item de lista) for D3cold, forneça um objeto _PR3 que inclui os recursos de energia que o dispositivo filho (inserido) requer para D3hot (por exemplo, Vcc e Vaux). Se as mesmas fontes de energia forem necessárias para D0, D2 e D3hot, _PR0, _PR2 e _PR3 especificar todos os mesmos recursos de energia. Esses recursos são desativados somente quando o dispositivo filho entra em D3cold.
Por motivos históricos, o Windows espera que _PR2 estejam presentes sempre que _PR0 estiver presente. Se D2 for implementado no hardware, _PR2 listará os recursos de energia necessários para D2. Se D2 não for implementado, _PR2 listará os mesmos recursos que _PR0.
Implementar _PR0. A lista de recursos no objeto _PR0 para o barramento pai deve incluir os recursos que alimentam o link que conecta o barramento pai ao dispositivo filho (inserido).
Exemplo (enumerado por barramento)
O exemplo de configuração de hardware no diagrama de bloco a seguir mostra duas maneiras diferentes de habilitar o D3cold para dispositivos PCIe. Primeiro, um ponto de extremidade (rotulado como ENDP) é conectado a uma porta raiz PCIe (RP01) e recebe energia auxiliar de seu dispositivo pai por meio de um link PCIe. Em segundo lugar, o dispositivo de áudio HD no diagrama não tem nenhum link padrão para seu dispositivo pai (o controlador PCI rotulado PCI0) e, portanto, é modelado de forma semelhante ao caso enumerado por ACPI.
O dispositivo RP01 neste diagrama tem uma fonte de energia main, Vcc1 e uma fonte de energia auxiliar, Vaux1. Da mesma forma, o dispositivo de áudio HD tem uma fonte de alimentação main, Vcc2 e uma fonte de alimentação auxiliar, Vaux2.
O código ASL a seguir descreve o controlador de barramento pai (PCI0) e os recursos de energia necessários para os dispositivos ENDP e HD Audio mostrados no diagrama anterior.
Scope (_SB)
{
Method(_OSC, 4, NotSerialized) // Platform-wide Capabilities Check.
{
... // This must indicate support for _PR3.
}
PowerResource(PVC1,0,0) // Power resource representing Vcc1 for the RP01 device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR0)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX1,0,0) // Power resource representing Vaux1 for the RP01 device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR1)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVC2,0,0) // Power resource representing Vcc2 for the HD device.
// Required for the device(s) to be fully functional (D0).
{
Name(_STA,VAR2)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
PowerResource(PVX2,0,0) // Power resource representing Vaux2 for the HD device.
// Required for low-power, less-functional states (e.g., D3hot).
{
Name(_STA,VAR3)
Method(_ON,0x0) {...}
Method(_OFF,0x0) {...}
}
... // Power resources for other child devices
Device(PCI0) // The PCI root complex
{
Name(_HID, EISAID("PNP0A08")) // ACPI enumerated
Method(_OSC, 4, NotSerialized) // PCIe-specific Capabilities Check.
{
... // This must support hand-off of PCIe control to the OS.
}
... // Other (non-power) objects for this device
Device(RP01) // PCIe Root Port 1
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC1, PVX1}) // Power resources required for D0.
// Includes the Link Power for ENDP.
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC1, PVX1})
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that
// can be handled while the platform is in S0.
// Enable wake events (optional)
// If this device actually does generate wake events, there must be a way
// for OSPM to enable and disable them. The mechanism for this depends on
// the platform hardware:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
Device(ENDP) // This device supports D3cold. No power-related objects
// are required.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects
} // End of Device ENDP
} // End of Device RP01
Device(HD) // A PCIe Bus0 device (HD Audio) that supports D3cold. Note that
// this case is modeled similar to the ACPI-enumerated case
// because device HD has no standard link to its parent.
{
Name(_ADR, "...") // Bus enumerated
... // Other (non-power) objects for this device
// Indicate support for D0.
Name(_PR0, Package() {PVC2, PVX2}) // Power resources required for D0
// Indicate support for D1 (optional)...
// Indicate support for D2.
Name(_PR2, Package(){PVC2, PVX2})
// Indicate support for D3Cold.
Name(_PR3, Package() {PVC2, PVX2}) // Power resource for D3; These will
// be turned off ONLY if drivers
// opt-in to D3cold.
// Indicate support for wake. Required for entry into D3cold, even if the
// device doesn't need or have a wake mechanism.
Name(_S0W, 4) // The existence of this object indicates that the platform
// is capable of handling wake events from this device
// while the platform is in S0.
// The value of this object indicates the lowest D-state
// this device can be in to trigger wake events that can
// be handled while the platform is in S0.
// Enable wake events (optional).
// If this device actually does generate wake events, there must be a way for
// OSPM to enable and disable them. The mechanism for this depends on the HW:
/*
Name(_PRW, ...) // If the event is signaled via a GPE bit (SCI) OR
// if there are power resources required only for wake.
Name(_CRS, ...) // If the event is signaled via a wake-capable interrupt.
Method(_DSW, 3) {...} // Can be used with both of the above, if wake
// enablement varies depending on the target
// S-state and D-state.
*/
} // End Device HD
... // Device objects for other child devices
} // End Device PCI0
} // End Scope _SB
Outras possibilidades
As técnicas mostradas nos dois exemplos anteriores podem ser combinadas para dar suporte a configurações que usam energia de barramento e energia de sideband.
Requisitos do driver de dispositivo
O proprietário da política de energia de um dispositivo (normalmente o driver de função) informa ao sistema operacional se deseja habilitar a transição do dispositivo de D3hot para D3cold. O driver pode fornecer essas informações no arquivo INF que instala o dispositivo. Ou o driver pode chamar a rotina SetD3ColdSupport em tempo de execução para habilitar ou desabilitar dinamicamente as transições do dispositivo para D3cold. Ao habilitar um dispositivo para inserir D3cold, um driver garante o seguinte comportamento:
O dispositivo pode tolerar uma transição de D3hot para D3cold quando o computador deve permanecer em S0.
O dispositivo funcionará corretamente quando retornar a D0 de D3cold.
Um dispositivo que não atende a nenhum dos requisitos pode, depois de inserir D3cold, ficar indisponível até que o computador seja reiniciado ou entre em um estado de suspensão. Se o dispositivo precisar ser capaz de sinalizar um evento de ativação de qualquer estado Dx de baixa potência que ele insere, a entrada em D3cold não deverá ser habilitada, a menos que o driver tenha certeza de que o sinal de ativação do dispositivo funcionará em D3cold.
Para obter mais informações, consulte Suporte a D3cold em um driver.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de