Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
A partir do Windows 8, os dispositivos podem entrar no subestado 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 D3cold para um dispositivo incorporado. A discussão a seguir destina-se a ajudar os desenvolvedores de firmware a permitir que seus dispositivos incorporados entrem e saiam do D3cold de forma confiável.
Além disso, os requisitos de driver de dispositivo para suportar D3cold são brevemente discutidos. Para obter mais informações sobre o suporte de drivers para dispositivos para D3cold, consulte Suporte ao D3cold num driver.
Introdução
Os estados de energia do dispositivo são definidos na especificação ACPI e em várias especificações de barramento. Desde que a especificação do barramento PCI introduziu a gestão de energia PCI, o estado de energia D3 (desligado) do dispositivo foi dividido em dois subestados: D3hot e D3cold. Esta distinção foi acrescentada à especificação ACPI na ACPI 3.0 e alargada na ACPI 4.0. O Windows sempre deu suporte a ambos os subestados D3, mas o Windows 7 e versões anteriores do Windows suportam o subestado D3cold somente quando toda a máquina 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 enquanto o sistema permanece no S0.
D3hot, que muitas vezes é chamado apenas de "D3", é o estado "soft-off" do dispositivo. Nesse estado, o dispositivo pode ser detetado por uma verificação de barramento e os comandos enviados para o dispositivo podem fazer com que ele ligue novamente. No D3cold, todas as fontes de alimentação são removidas, com a possível exceção de uma pequena quantidade de energia para acionar a lógica de despertar do dispositivo. Por exemplo, para dispositivos PCI Express (PCIe), a fonte de alimentação do dispositivo principal, Vcc, é frequentemente desligada em uma transição para D3cold. Desligar o Vcc pode reduzir o consumo de energia e prolongar o tempo que uma plataforma de hardware móvel pode funcionar com uma carga de bateria. Quando um dispositivo está em D3cold, ele não pode ser detetado por uma varredura de barramento e não pode receber comandos. Restaurar a energia Vcc move o dispositivo para um estado não inicializado, que geralmente é equivalente ao estado D0. O software deve então reinicializar o dispositivo para colocá-lo no estado de trabalho.
Colocar um dispositivo em D3cold não significa necessariamente que todas as fontes de energia do dispositivo foram removidas — significa apenas que a fonte de alimentação principal, Vcc, foi removida. A fonte de alimentação auxiliar, Vaux, também pode ser removida se não for necessária para a lógica de despertar. No entanto, um dispositivo que possa ser necessário para sinalizar um evento de despertar para o processador deve ser capaz de extrair energia suficiente para operar a lógica de despertar. Por exemplo, uma placa de interface de rede Ethernet (NIC) cuja fonte de alimentação principal é removida pode extrair energia suficiente do cabo Ethernet. Ou, a alimentação em standby para uma NIC Wi-Fi pode ser fornecida a partir de uma fonte fora da interface PCIe, caso em que a interface PCIe pode ser completamente desligada.
Na discussão a seguir, um conjunto de requisitos é descrito para habilitar transições de estado de energia do dispositivo para D3cold. Estes requisitos inserem-se nas duas categorias seguintes:
Requisitos de firmware e plataforma
Requisitos do driver de dispositivo
A primeira destas duas categorias é o foco principal desta discussão. É apresentada uma breve panorâmica da segunda categoria. Para obter mais informações sobre os requisitos de controlador de dispositivo, consulte Suporte ao D3cold num controlador.
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 em ACPI.
Quando o dispositivo é enumerado pelo seu barramento pai.
A maior parte da discussão a seguir é específica para PCIe. No entanto, os princípios gerais aqui descritos aplicam-se, em grande medida, também a outros autocarros.
Abstraindo alguns detalhes, a transição de D3cold para D0 é desencadeada pela reaplicação de energia Vcc ao dispositivo incorporado. A reaplicação da energia restaura com eficácia 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, em seguida, reinserido.
Se os identificadores corresponderem, o driver de dispositivo reinicializa o dispositivo. Se os identificadores não corresponderem, o Windows remove o controlador de dispositivo e cria uma nova pilha de controladores para o novo dispositivo. O 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 conectado anteriormente depois que a energia for reaplicada (e o período de espera especificado pelo barramento passar); caso contrário, o Windows considerará o novo dispositivo diferente do anterior.
Caso 1: Um dispositivo incorporado é enumerado na ACPI
Se um dispositivo incorporado não for detectável através de mecanismos definidos por uma especificação de bus, como PCIe ou USB, mas o dispositivo estiver permanentemente conectado (ou pelo menos a conexão for dedicada a um dispositivo conhecido), esse dispositivo pode ser descrito no firmware da plataforma por objetos _HID e/ou _CID ACPI. 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 detetar a ID do dispositivo. Por exemplo, dispositivos num barramento ISA são enumerados pelo OSPM. Além disso, os dispositivos em um(a) Sistema em um Chip (SoC) são frequentemente enumerados pela ACPI porque estão em uma infraestrutura não enumerável. Exemplos de tais dispositivos incluem controladores host USB e SD.
Firmware de plataforma (enumerado em ACPI)
O OSPM usa \_SB._OSC para transmitir capacidades OSPM na plataforma inteira para o firmware da plataforma. O firmware da plataforma deve definir o bit 2 no valor de retorno \_SB._OSC para indicar ao OSPM que o dispositivo suporta _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 incorporado (descoberto unicamente através de ACPI)
Para suportar o D3cold, o firmware da plataforma deve implementar os seguintes objetos de recursos de energia ACPI para o dispositivo incorporado:
_PR0: Este objeto avalia os requisitos de energia do dispositivo no estado de energia do dispositivo D0 (totalmente ligado). O valor de retorno é 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 do dispositivo D2. O valor de retorno é a lista de recursos de energia que o dispositivo requer no estado D2. Observe que, por razões históricas, o Windows espera que _PR2 esteja presente sempre que _PR0 estiver presente. Se D2 for implementado no hardware, _PR2 lista 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 do dispositivo D3hot. O valor de retorno é 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 desligado (desligue o recurso).
_ON: Defina o recurso de energia para o estado ativado (poder no recurso).
_STA: Este objeto avalia o estado atual ligado ou desligado do recurso de alimentação (0: desligado, 1: ligado).
Uma transição para D3cold acontece quando a ACPI executa o método de controle de _OFF nos recursos de energia listados no _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 entre e permaneça em D3hot por um longo período e, em seguida, retorne a D0 sem nunca entrar em D3cold ou entre em D3cold posteriormente.
Dispositivo principal (enumerado em ACPI)
Não é necessário que um dispositivo pai tenha a capacidade de gestão de energia. No entanto, se um dispositivo pai for gerido por energia, o Windows nunca desativará esse dispositivo se algum de seus filhos (dispositivos dependentes) não estiver no estado D3.
Exemplo (enumerado em ACPI)
O diagrama de blocos a seguir mostra um dispositivo incorporado (rotulado EMBD) em um barramento do sistema. A alimentação principal (Vcc) e a potência auxiliar (Vaux) do dispositivo podem ser ligadas e desligadas de forma independente através do bloco rotulado como lógica de energia.
O exemplo de código ASL a seguir descreve os recursos de energia usados pelo dispositivo incorporado no diagrama anterior. Este exemplo começa com uma declaração de um método de controle de _OSC que descreve os recursos do driver de dispositivo. Em seguida, os dois recursos de energia do dispositivo são declarados — os nomes dos recursos PVCC e PVAX são atribuídos às fontes de alimentação principais e auxiliares do dispositivo, Vcc e Vaux. Finalmente, os requisitos de recursos de energia são listados para cada estado de energia do dispositivo suportado pelo dispositivo e os recursos de despertar 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 incorporado é enumerado através do barramento
Se o dispositivo incorporado estiver em conformidade com uma especificação de barramento comum, como PCIe ou USB, este dispositivo poderá ser descoberto através de mecanismos definidos pelo barramento e a energia poderá ser fornecida totalmente ou parcialmente através do barramento. Se este dispositivo não for alimentado através de outros recursos de energia de banda lateral, a principal fonte de alimentação do dispositivo é a ligação 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 incorporado. Um objeto _ADR é utilizado para fornecer ao OSPM o endereço de um dispositivo no barramento-mãe do dispositivo embutido. Este endereço é utilizado para associar a forma como o dispositivo é representado pelo barramento (conforme visível pelo hardware do barramento) à forma como o dispositivo é representado na plataforma (conforme visível 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 ACPI 5.0.) Quando este mecanismo é empregado, o suporte D3cold deve ser coordenado com o motorista do ônibus pai.
Se a principal fonte de alimentação de um dispositivo incorporado for a ligação que conecta esse dispositivo ao barramento pai, o requisito principal para colocar o dispositivo em D3cold é desligar a ligação. Para obter mais informações sobre a transição para D3cold, consulte o gráfico de estado em Device Power States.
Firmware da plataforma (enumerado em bus)
O OSPM usa \_SB._OSC para transmitir as capacidades OSPM a nível de plataforma ao firmware da plataforma. O firmware da plataforma deve configurar o bit 2 no valor de retorno \_SB._OSC para informar ao OSPM que o dispositivo é compatível com o _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 incorporado (enumerado por barramento)
Não são necessárias alterações ACPI específicas do D3cold. Nesse caso, desde que o driver de dispositivo e a plataforma tenham indicado suporte para D3cold, o link de barramento que fornece energia ao dispositivo incorporado pode ser desligado quando o barramento pai sair de D0 e entrar em um estado Dx de baixo consumo de energia. A transição do dispositivo incorporado de D3hot para D3cold ocorre quando a energia é removida do link. O estado Dx em que o barramento pai entra pode ser qualquer estado que provoque o desligamento da fonte de alimentação do link.
Dispositivo pai (enumerado por barramento)
O descritor ACPI para o barramento pai deve fazer o seguinte:
Implemente _S0W(Dx). Este objeto especifica Dx como o estado D de menor potência a partir do qual o dispositivo filho (incorporado) pode despertar quando o sistema está no estado S0.
Definir recursos de potência para representar a ligação que conecta o dispositivo filho (incorporado) ao barramento pai. Além disso, objetos _ON, _OFF e _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 _STA objetos são definidos.
Se "Dx" (o estado D de menor potência; consulte o primeiro item da lista) for D3cold, forneça um objeto _PR3 que inclua os recursos de energia que o dispositivo filho (incorporado) necessita para operar em D3hot (por exemplo, Vcc e Vaux). Se as mesmas fontes de alimentação forem necessárias para D0, D2 e D3hot, _PR0, _PR2 e _PR3 especificam os mesmos recursos de energia. Esses recursos são desativados somente quando o dispositivo filho entra no D3cold.
Por razões históricas, o Windows espera que _PR2 esteja presente sempre que _PR0 estiver presente. Se D2 for implementado no hardware, _PR2 lista os recursos de energia necessários para D2. Se D2 não for implementado, _PR2 listará os mesmos recursos que _PR0.
Implemente _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 (incorporado).
Exemplo (enumerado pelo bus)
O exemplo de configuração de hardware no diagrama de blocos a seguir mostra duas maneiras diferentes de habilitar o D3cold para dispositivos PCIe. Primeiro, um ponto de extremidade (rotulado ENDP) é conectado a uma porta raiz 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 ACPI.
O dispositivo RP01 neste diagrama tem uma fonte de alimentação principal, Vcc1, e uma fonte de alimentação auxiliar, Vaux1. Da mesma forma, o dispositivo de áudio HD tem uma fonte de alimentação principal, 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 suportar configurações que usam energia de barramento e energia de banda lateral.
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 deve 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 ativar ou desativar dinamicamente as transições do dispositivo para D3cold. Ao permitir que um dispositivo entre no 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 ao D0 do D3cold.
Um dispositivo que não atenda a nenhum dos requisitos pode, depois de entrar no D3cold, ficar indisponível até que o computador seja reiniciado ou entre em estado de suspensão. Se o dispositivo deve ser capaz de sinalizar um evento de despertar a partir de qualquer estado Dx de baixa potência em que entra, a entrada para D3cold não deve ser permitida, a menos que o driver tenha certeza de que o sinal de despertar do dispositivo funcionará em D3cold.
Para obter mais informações, consulte Suportar D3cold num controlador.