Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A partir do Windows 8, os dispositivos podem entrar no 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 a 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 da D3cold de forma confiável.
Além disso, os requisitos de driver de dispositivo para dar suporte a D3cold são discutidos brevemente. Para obter mais informações sobre o suporte de driver para D3cold, consulte Como oferecer 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 barramentos. A especificação do barramento PCI, desde que foi introduzido 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 de ACPI no ACPI 3.0 e estendida no ACPI 4.0. O Windows sempre deu suporte a ambos os 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. A partir do Windows 8, os drivers de dispositivo podem permitir que seus dispositivos entrem no estado D3cold mesmo que o sistema permaneça 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 energia do dispositivo principal, 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 varredura de barramento e não pode receber comandos. Restaurar a energia da 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 principal, 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 despertar. 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 (placa de adaptador de rede) Ethernet cuja fonte de energia principal é removida pode extrair energia suficiente do cabo Ethernet. Ou, a energia de espera para uma NIC em estado Wi-Fi pode ser fornecida de uma fonte externa à interface PCIe, caso em que 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 de driver de dispositivo
A primeira dessas duas categorias é o foco principal dessa 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 ao 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 pelo 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.
Ao abstrair alguns detalhes, a transição de D3cold para D0 é disparada pela aplicação novamente da energia Vcc ao dispositivo incorporado. Reaplicar energia de forma eficaz restaura 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 drivers para o novo dispositivo. PCIe, por exemplo, consulta o ID do fornecedor, o ID do dispositivo e os IDs do subsistema (que são divididos em IDs de subdispositivo e subfornecedor em algumas versões da especificação). Esses identificadores devem corresponder aos do dispositivo anexado anteriormente depois que a energia for reaplicada e o período de espera especificado pelo barramento tiver 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 de 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 (System on a Chip) geralmente são enumerados pela 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 as capacidades 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 de ACPI)
Para dar suporte ao D3cold, o firmware de plataforma deve implementar os seguintes objetos de recurso de energia ACPI para o dispositivo inserido:
_Pr0: Este objeto determina os requisitos de energia do dispositivo no estado de energia do dispositivo D0 (completamente ligado). O valor retornado é a lista de recursos de energia que o dispositivo requer no estado D0.
_PR2: Este objeto avalia os requisitos de energia do dispositivo no estado de energia 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: Este objeto avalia os requisitos de energia do dispositivo no estado de energia 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 (energia no recurso).
_STA: Este objeto é avaliado quanto ao estado atual ligado ou desligado do recurso de energia (0: desligado, 1: ligado).
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 implicará que todas as transições para D3 resultem em transições rápidas para D3cold. É possível que o dispositivo entre e permaneça em D3hot por um período estendido e, em seguida, retorne a D0 sem nunca entrar em D3cold, ou entre em 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 embarcado rotulado EMBD em um barramento do sistema. A alimentação principal (Vcc) e a alimentação auxiliar (Vaux) para o dispositivo podem ser ativadas e desativadas independentemente por meio do bloco rotulado Lógica de Potência.
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 de 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 principais e auxiliares do dispositivo, Vcc e Vaux. Por fim, os requisitos de fonte de alimentação são listados para cada estado de energia suportado pelo dispositivo, e suas capacidades de ativação são descritas.
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 inteiramente por meio do barramento. Se esse dispositivo não for alimentado por outros recursos de energia de sideband, a principal fonte de energia do dispositivo será o link que conecta o dispositivo ao controlador de barramento pai. Os dispositivos enumerados por barramento podem ser identificados pelo objeto _ADR na definição do dispositivo inserido. Um objeto _ADR é usado para fornecer ao OSPM o endereço de um dispositivo no barramento pai do dispositivo embarcado. Esse endereço é usado para vincular a representação do dispositivo pelo barramento (conforme visto pelo hardware do barramento) à representação do dispositivo pela plataforma (como visto pelo firmware ACPI). (A codificação de endereços _ADR é específica do barramento. Para obter mais informações, consulte a seção 6.1.1, "_ADR (Endereço)", na especificação ACPI 5.0.) Quando esse mecanismo é empregado, o suporte a D3cold deve ser coordenado com o motorista do ônibus pai.
Se a fonte de energia principal de um dispositivo embarcado for o link que conecta esse dispositivo ao barramento pai, o principal requisito para colocar o dispositivo em D3cold é desligar o link. Para obter mais informações sobre a transição para D3cold, consulte o gráfico de estado nos Estados de Energia do Dispositivo.
Firmware de plataforma (enumerado em barramento)
O OSPM usa \_SB._OSC para transmitir capacidades 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 do dispositivo e a plataforma tenham indicado suporte para D3cold, o link do barramento que fornece energia para o dispositivo incorporado pode ser desativado quando o barramento pai sair de D0 e entrar em um estado de baixa potência Dx. A transição do dispositivo embutido de D3hot para D3cold ocorre quando a fonte de energia é removida do link. O estado Dx em que o barramento pai entra pode ser qualquer estado que leve à desativação da fonte de energia do link.
Dispositivo pai (enumerado por barramento)
O descritor ACPI para o barramento pai deve fazer o seguinte:
Implementar _S0W(Dx). Esse objeto especifica Dx como o estado D de menor potência do qual o dispositivo filho (inserido) pode acordar quando o sistema está no estado S0.
Defina recursos de energia para representar a conexão que liga o dispositivo filho (embutido) 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 consumo de energia; ver o primeiro item da lista) for D3cold, forneça um objeto _PR3 que inclua os recursos de energia que o dispositivo filho (incorporado) 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 a conexão que conecta o barramento pai ao dispositivo filho (embutido).
Exemplo (enumerado em barramento)
A configuração de hardware de exemplo no diagrama de bloco a seguir mostra duas maneiras diferentes de habilitar o D3cold para dispositivos PCIe. Primeiro, um endpoint (rotulado ENDP) é conectado a uma porta root PCIe (RP01) e recebe energia auxiliar de seu dispositivo pai através 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 principal, Vcc1 e uma fonte de energia auxiliar, Vaux1. Da mesma forma, o dispositivo de áudio HD tem uma fonte de energia principal, Vcc2 e uma fonte de energia auxiliar, Vaux2.
O seguinte código ASL descreve o controlador de barramento principal (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 tanto a energia de barramento quanto a energia de subbanda.
Requisitos de 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 qualquer requisito pode, depois de inserir D3cold, ficar indisponível até que o computador seja reiniciado ou insira um estado de suspensão. Se o dispositivo precisar ser capaz de sinalizar um evento de ativação a partir de qualquer estado Dx de baixa potência em que ele entrar, a transição para 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, veja Suporte a D3cold em um driver.