Patent ID: 12222792

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

FIG.1is a block diagram of a battery-powered information handling system100(e.g., a client information handling system such as a laptop computer, notebook computer, tablet computer, convertible computer, cell phone, etc.) as it may be configured according to one embodiment of the disclosed systems and methods. In this regard, it should be understood that the configuration ofFIG.1is exemplary only, and that the disclosed methods may be implemented on other types of information handling systems. It should be further understood that while certain components of an information handling system are shown inFIG.1for illustrating embodiments of the disclosed systems and methods, the information handling system is not restricted to including only those components shown inFIG.1and described below.

As shown inFIG.1, information handling system100may generally include a host programmable integrated circuit110executing an operating system (OS)101(e.g., proprietary OS such as Microsoft Windows 10, open source OS such as Linux OS, etc.) and BIOS194for system100, as well as other code such as user software applications102(e.g., word processing application, Internet browser, computer game, PDF viewer, spreadsheet application, etc.), etc. In the embodiment ofFIG.1, host programmable integrated circuit110may be configured to access non-volatile memory190(e.g., serial peripheral interface (SPI) Flash memory) to load and boot part of a system BIOS194. Host programmable integrated circuit110may include any type of processing device, such as an Intel central processing unit (CPU), an Advanced Micro Devices (AMD) CPU or another programmable integrated circuit. Host programmable integrated circuit110is coupled as shown to system volatile memory120, which may include, for example, random access memory (RAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), etc.

In the illustrated embodiment, host programmable integrated circuit110may be coupled to an external or internal (integrated) display device140(e.g., LCD or LED display or other suitable display device) depending on the particular configuration of information handling system100. In such an embodiment, integrated graphics capability may be implemented by host programmable integrated circuit110to provide visual images (e.g., a graphical user interface, static images and/or video content) to a system user. However, in other embodiments, a separate programmable integrated circuit (e.g., such as graphics processor unit “GPU”) may be coupled between host programmable integrated circuit110and display device140to provide graphics capability for information handling system100.

In the exemplary embodiment ofFIG.1, PCH150controls certain data paths and manages information flow between certain components of information handling system100. As such, PCH150may include one or more integrated controllers or interfaces for controlling the primary data paths connecting PCH150with host programmable integrated circuit110and input/output (I/O) devices170forming at least a part of a user interface for the information handling system, out-of-band programmable integrated circuit (e.g., embedded controller)180, and system NVM190where BIOS firmware image and settings197may be stored together with other components such as ACPI firmware, etc. In one embodiment, PCH150may include a Serial Peripheral Interface (SPI) controller and an Enhanced Serial Peripheral Interface (eSPI) controller. In some embodiments, PCH150may include one or more additional integrated controllers or interfaces such as, but not limited to, a Peripheral Controller Interconnect (PCI) controller, a PCI-Express (PCIe) controller, a low pin count (LPC) controller, a Small Computer Serial Interface (SCSI), an Industry Standard Architecture (ISA) interface, an Inter-Integrated Circuit (I2C) interface, a Universal Serial Bus (USB) interface and a Thunderbolt™ interface.

As shown inFIG.1, battery charger and power circuitry175is included within information handling system100to receive input DC power from multiple power sources, and is coupled to provide regulated DC output power and operating voltage on one or more power rails176to various power-consuming components of information handling system100. Power for information handling system100may be provided to battery charger and power circuitry175from an external power source (e.g., AC mains151through AC adapter155), and/or from an internal power source in the form of battery system165(e.g., a lithium ion (“Li-ion”) or nickel metal hydride (“NiMH”) smart battery pack). It will be understood that external power may be alternatively provided to information handling system100from any other suitable external power source (e.g., such as an external DC power source) or that AC adapter155may alternatively be integrated within information handling system100, e.g., such that AC mains151supplies AC power directly to components inside chassis enclosure103of information handling system100. In the illustrated embodiment, AC adapter155is removably coupled to, and separable from, battery charger and power circuitry175of information handling system100at mating interconnection terminals191and192in order to provide information handling system100with a source of DC power to charge battery cells167of battery system165across power conductor/s163and/or to supplement or replace DC power provided across power conductor/s163by battery cells167of battery system165.

Battery system165(e.g., smart battery or smart battery pack) may include one or more rechargeable batteries (with each battery containing battery cells167) and a BMU166that itself may include, for example, an analog front end (“AFE”), storage (e.g., non-volatile memory) and microcontroller173. BMU165may be coupled to control switching circuitry169(e.g., metal-oxide-semiconductor field-effect transistors “MOSFET”) within battery system165to control flow of discharging current from battery cells167and flow of charging current to battery cells167. BMU165may also be coupled via its AFE to sense battery system operating conditions such as remaining battery power capacity (e.g., state of charge), battery current and voltage, etc. Battery charger and power circuitry175of information handling system100provides output power for power rail/s176that power a system load (power-consuming components) of information handling system100. Battery charger/power circuitry175also provides DC power across power conductor/s163for charging battery cells167of the battery system165during battery charging operations. Further information on BMU, battery pack and battery charging operations may be found in U.S. Pat. Nos. 7,378,819, 7,391,184, 8,138,722 and 9,300,015, each of which is incorporated herein by reference in its entirety for all purposes.

As further shown inFIG.1, a battery system data bus (e.g., system management bus “SMBus”)181may be coupled to battery system165to provide real time and/or stored information (e.g., battery system operating conditions such as state of charge, battery current and voltage) from BMU166of battery system165to embedded controller (EC)180. EC180may also provide data and/or commands across data bus181to BMU166of battery system165(e.g., to instruct BMU166to control operation of switching circuitry169within battery system165).

In one embodiment, battery system165may be contained within a cavity of a battery compartment that is defined within chassis enclosure103of information handling system100. In one such embodiment, battery system165may be an interchangeable or user-replaceable battery pack that is provided with external power and data connector terminals for contacting and making temporary (e.g., non-soldered) interconnection with mating power connector terminals and data connector terminals provided within the battery pack compartment, e.g., to exchange power through power conductors163with battery charger and power circuitry175of the information handling system100, as well as to exchange data across data bus181with EC180of the information handling system100. In another embodiment, battery system165may be a non-replaceable or permanent battery pack that is enclosed (or captured) within information handling system chassis enclosure103and may have power connector terminals and data connector terminals that are optionally soldered to power conductors163and data bus181. Further information with respect to example operation and configuration of battery system165may be found, for example, in U.S. Pat. No. 7,595,609, in U.S. Pat. No. 7,436,149, and in U.S. Pat. No. 10,496,509, each of which is incorporated herein by reference in its entirety for all purposes.

As shown, external and/or internal (integrated) I/O devices170(e.g., a keyboard, mouse, touchpad, touchscreen, etc.) may be coupled to PCH150of system100to enable a human user to input data and interact with information handling system100, and to interact with application programs or other software/firmware executing thereon.

Also shown present inFIG.1is local system storage in the form of solid state drive (SSD)160that is coupled through PCIe bus (PCIe link)135via PCIe endpoint (EP)139to PCIe host root complex (RC)136of host programmable integrated circuit110. As shown, SSD160includes main system non-volatile storage media provided in the form of solid state drive memory elements161for storing code, data, instructions for use by various components (e.g., including host programmable integrated circuit110) of system100. SSD160also includes a storage system programmable integrated circuit in the form of an integrated microcontroller (μC)164that is coupled to integrated dedicated non-volatile memory162(e.g., dedicated Flash memory) of SSD160that is dedicated for storing data, code and instructions for use by storage system programmable integrated circuit164. In this regard, dedicated non-volatile memory162is separate and different from main system non-volatile storage media161that is used for storing user data and other data for system100. Besides a microcontroller, a storage system programmable integrated circuit164may alternatively be another suitable type of programmable integrated circuit, e.g., such as FPGA, ASIC, etc.

In the embodiment ofFIG.1, PCIe bus (PCIe link)135provides a communication path between host programmable integrated circuit110and system solid state drive (SSD)160. As shown, host programmable integrated circuit110may include an integrated PCIe microcontroller that implements a host PCIe root complex136that is coupled via PCIe link135to an integrated PCIe endpoint microcontroller139of SSD160, i.e., so as to implement PCIe features and to enable exchange of PCIe communications and data, commands, instructions between host programmable integrated circuit110and SSD160.

As shown inFIG.1, EC180is coupled to PCH150and may include integrated microcontroller189(or other integrated programmable integrated circuit) that is programmed to perform the tasks of SSD power mode control logic183that controls PCIe link power and that controls SSD power mode as described elsewhere herein. EC180may also be programmed to execute program instructions to boot information handling system100, execute thermal system management, etc. EC180may include, for example, an integrated microcontroller189or other integrated programmable integrated circuit such as microprocessor, ASIC, or programmable logic device “PLD” such as FPGA, complex programmable logic device “CPLD”, etc. In one embodiment, integrated programmable integrated circuit189of EC180may operate as an out-of-band programmable integrated circuit that is separate and independent from in-band host programmable integrated circuit110running the host OS101, and integrated programmable integrated circuit189of EC180may execute without management of any application or other logic executing on host OS101.

As shown in the exemplary embodiment ofFIG.1, EC180is coupled to PCH150via data bus185, and NVM190is coupled to PCH150via data bus195. According to one embodiment, data bus195is a Serial Peripheral Interface (SPI) bus, and data bus185is an Enhanced Serial Peripheral Interface (eSPI) bus. In the embodiment shown inFIG.1, NVM190may be a SPI Flash memory device that is a shared Flash memory device, which is connected to PCH150and EC180. In such a configuration, PCH150provides EC180shared access to NVM190via eSPI bus185, SPI bus195, and various interface and logic blocks included within the PCH150. As further shown, SMBus161also couples microcontroller189of EC180in data communication with microcontroller164of SSD160.

FIG.2illustrates a block diagram of circuitry200configured to detect battery power capacity (e.g., battery state of charge) and control SSD power mode according to one exemplary embodiment of the disclosed systems and methods. As shown inFIG.2. EC180may be coupled by SMBus181to each of BMU166(of battery system165) and SSD160, and SMBus181may include SMBus clock signal (SMBCLK)210and SMBus data signal (SMBDAT)212. InFIG.2. EC180may operate as a SMBus master. In the embodiment ofFIG.2, BMU166of battery system165detects the remaining power status (e.g., battery SOC) of battery system165by making electrical measurements of battery cells167. In this embodiment, SMBus is a form of I2C protocol that is used to communicate between EC180, BMU166(of battery system165), and SSD160.

In the embodiment ofFIG.2, SSD power mode control logic183executing on integrated microcontroller189of EC180periodically polls integrated microcontroller173of BMU166(e.g., using a unique command identifier) across SMBus181to obtain a current value of the remaining battery power capacity (e.g., SOC) of battery cells167of battery system165. Integrated microcontroller173of BMU166of battery system165responds to each such poll event from EC180by providing the latest measured remaining battery power capacity value (e.g., SOC) of battery cells167of battery system165across SMBus181to SSD power mode control logic183executing on integrated microcontroller189of EC180. As described further herein in relation toFIG.3, SSD power mode control logic183executing on integrated microcontroller189of EC180then analyzes the latest measured remaining battery power capacity (e.g., SOC) of battery cells167of battery system165to determine whether or not SSD power mode should be set to low battery SSD power mode or relatively higher SSD power mode. Then based on this determination and the current SSD power mode of SSD160, integrated microcontroller189of EC180may provide a command across SMBus181to integrated microcontroller164of SSD160to cause SSD160to enter or continue the low battery SSD power mode, or to exit from the low battery SSD power mode, as the case may be.

FIG.3illustrates one exemplary embodiment of a methodology300which may be implemented (e.g., by SSD power mode control logic183executing on microcontroller189of EC180and PCIe link and NVMe power control logic160executing on microcontroller (μC)164of SSD160) when the current remaining battery capacity is greater than a minimum operating SOC value (e.g., greater than a critical battery level or minimum SOC value such as 5% or any other predefined greater of lesser minimum SOC value) that is required to execute active host OS101and/or user application/s102on host programmable integrated circuit, to receive user input via I/O devices170, and to display video information to the user on display device140. Methodology300may be so implemented when the current remaining battery capacity is greater than a critical battery level or minimum operating SOC value to detect current remaining battery power capacity (e.g., battery state of charge) and control SSD power mode based on the current remaining battery power capacity and dynamically change the SSD power mode when needed, e.g., using the circuitry ofFIGS.1and2.

Although described only for purposes of illustration with reference toFIGS.1and2, it will be understood that methodology300ofFIG.3may be implemented in a similar manner using any alternative configuration of information handling system circuitry in which a first programmable integrated circuit that is external to a battery system and a solid state drive communicates with a second programmable integrated circuit that is internal to a battery system and a third programmable integrated circuit that is internal to a solid state drive.

Still referring toFIG.3, methodology300begins in block302where SSD power mode control logic183on EC183periodically issues a battery data/status request across SMBus181to BMU166of battery system165. SSD power mode control logic183may issue this battery data/status request, for example, once every 5 minutes or any other suitable predefined greater or lesser time. In block304, Microcontroller173of BMU166of battery system165responds across SMBus181to each poll request from SSD power mode control logic183of EC180by transmitting a reply to SSD power mode control logic183of EC180that includes a report of the current value of the remaining battery capacity of battery cells167, e.g., SOC expressed in a percentage, where 0%=empty (or no remaining battery capacity) and 100%=full remaining battery capacity.

Next, in block306, SSD power mode control logic183on EC180determines if the current value of the remaining battery capacity of battery cells167currently reported by BMU166is less than or equal to a predefined low battery capacity threshold value (e.g., such as 20% SOC value or any other configurable predefined threshold of greater or lesser SOC value) that is greater than the designated critical battery level or minimum state of charge (e.g., such as 5% or any other predefined greater or lesser minimum state of charge below which information handling system automatically goes into hibernation or shuts down) with no external power currently being provided from AC adapter155to battery power and charger circuit175. If SSD power mode control logic183determines in block306that the reported current value of the remaining battery capacity of battery cells167is less than or equal to the predefined low battery capacity threshold value and no external power is currently being provided from AC adapter155to battery power and charger circuit175, then methodology300proceeds to block308where SSD power mode control logic183on EC180transmits a predefined “Enter low battery SSD power mode” power mode command across SMBus181to SSD160.

If in block310, SSD160is not currently operating in the low battery SSD power mode (i.e., SSD160is operating in a SSD power mode that is relatively higher than low battery SSD power mode), then methodology300proceeds to block312where PCIe link and NVMe power control logic160executing on microcontroller (μC)164of SSD160responds to the “Enter low battery SSD power mode” command of block308by causing SSD160to enter the low battery SSD power mode which is described further herein in relation toFIG.4. However, if in block310SSD160is currently operating in the low battery SSD power mode then methodology300proceeds to block314where microcontroller (μC)164of SSD160causes SSD160to continue operating in the low battery SSD power mode. Methodology300then returns from block310or312(as the case may be) to block302and iteratively repeats as shown.

Returning to block306, if SSD power mode control logic183on EC180determines that the reported current value of the remaining battery capacity of battery cells167is greater than the predefined low battery capacity threshold value and/or external power is currently being provided from AC adapter155to battery power and charger circuit175, then methodology300proceeds to block316where SSD power mode control logic183on EC180transmits a predefined “Exit low battery SSD power mode” power mode command across SMBus181to SSD160. Next, in block318, if SSD160is currently operating in the low battery SSD power mode then methodology300proceeds to block320where PCIe link and NVMe power control logic160on microcontroller (μC)164of SSD160responds to the “Exit low battery SSD power mode” command of block308by causing SSD160to exit the low battery SSD power mode to an SSD power mode that is relatively higher than the low battery SSD power mode. However, if in block318SSD160is currently operating in a SSD power mode that is relatively higher than the low battery SSD power mode, then methodology300proceeds to block322where PCIe link and NVMe power control logic160on microcontroller (μC)164of SSD160causes SSD160to continue operating in the relatively higher SSD power mode. Methodology300then returns from block320or322(as the case may be) to block302and iteratively repeats as shown.

It will understood that the particular combination of blocks of methodology300is exemplary only, and that other combinations of fewer, additional and/or alternative blocks may be employed that are suitable for detecting current remaining battery power capacity and controlling SSD power mode based on the detected remaining battery power capacity.

FIG.4illustrates one exemplary embodiment of a methodology400which may be implemented (e.g., by PCIe link and NVMe power control logic160on microcontroller164of SSD160) to implement SSD power mode in response to power mode commands received from EC180according to methodology300ofFIG.3, e.g., using the circuitry ofFIGS.1and2. Although described only for purposes of illustration with reference toFIGS.1and2, it will be understood that methodology400may be implemented in a similar manner using any alternative configuration of information handling system circuitry in which a first programmable integrated circuit that is external to a battery system and a solid state drive communicates with a second programmable that is internal to a solid state drive.

As shown inFIG.4, methodology400begins in block402where PCIe link and NVMe power control logic160on microcontroller164of SSD160receives a predefined power mode command of iterative methodology300across SMBus181from EC180. If in block404the current received power mode command of block402is determined to be an “Enter low battery SSD power mode” power mode command, then methodology400proceeds to block406where PCIe link and NVMe power control logic160on microcontroller164of SSD160causes SSD160to dynamically change to begin (or continue) operating in a low battery SSD power mode having low battery mode PCIe link power management settings and low battery mode NVMe power settings.

After block406, SSD160operates in low battery SSD power mode of block408using low battery mode PCIe link power management settings for SSD input/output (I/O) by aggressively transitioning the PCIe link power mode of PCIe link135into the L1.2 link power mode in a shorter period of time than is used in normal battery mode in order to reduce power consumption of both the SSD160and host programmable integrated circuit110. In one exemplary embodiment, host programmable integrated circuit110may then enter a lower power saving mode or “C-state”, and in some cases may enter its deepest power saving modes or “C-states” (e.g., such as C8, C9, C10 states) when applicable to further conserve remaining capacity of battery cells167. In this regard, host programmable integrated circuit110can only enter its deepest power saving modes or C-states (e.g., such as C8, C9, C10 states) if its endpoint device PCIe links are currently in the L1.2 link power mode, i.e., in which no system clock is maintained on PCIe link135by host PCIe root complex136. In another exemplary embodiment, host programmable integrated circuit110may operate in a C-state that allows it to continue to execute the host OS101and/or user application/s102during the low battery SSD power mode of block408, and SSD160may respond to host input/output I/O data requests (i.e., host read and write requests) transmitted from the host programmable integrated circuit110during the low battery SSD power mode of block408.

For example, to preserve limited remaining battery capacity during low battery SSD power mode of block408, low battery mode PCIe link power management settings may be employed that include a predefined low battery idle timeout value (e.g., a SSD self-idle timer value of 5 milliseconds to 10 milliseconds, SSD self-idle timer value of 10 milliseconds, SSD self-idle timer value of less than 20 milliseconds, etc.) that is less than (or shorter time than) the normal battery idle timeout or SSD self-idle timer value (e.g., 60 milliseconds) while operating in the PCIe Specification (e.g., L1 PM Substates with CLKREQ, Revision 1.0a, May 30, 2013) L0 link power mode (i.e., where both SSD160and host programmable integrated circuit110have full power to communicate across PCIe link135) during link idle before transitioning into the L1.2 link power mode. Expiration of this predefined low battery idle timeout value puts SSD160reporting as Active Idle, and PCIe link135switches to lower link power states of PCIe Specification power modes L1.0/L1.2 to save more battery power consumption. The predefined low battery idle timeout value used during low battery SSD power mode may be less than (or shorter than) the predefined normal battery idle timeout value of the normal battery mode PCIe link power management settings that are employed during normal battery SSD power mode (descried further below). In this way the link power mode of PCIe link135may be dynamically controlled by SSD160, rather than using the conventional technique where the link power mode of a PCIe link is controlled by a host root complex.

In addition to using this relatively shorter predefined low battery idle timeout value in PCIe Specification L0 link power mode, the value of low battery latency tolerance request (LTR) time used by SSD160during low battery mode PCIe link power management may be increased (or set to “No Requirement”) from the predefined positive normal battery LTR time value (e.g., 150 microseconds) used during normal battery SSD power mode. In this regard, the smaller the LTR value, the faster host PCIe root complex136needs to provide the PCIe clock across PCIe link135when link power mode transitions from PCIe Specification L1.2 link power mode to L0 link power mode, which obstructs host programmable integrated circuit110from entering a deep power saving mode. By setting LTR to be “No Requirement” in one embodiment, host programmable integrated circuit110is enabled to enter from its full power C0 state or other relatively higher “C-state” (e.g., such as C6 state) into its relatively lower deep power saving modes or C-states (e.g., such as C8, C9, C10 state) when PCIe link135is in the L1.2 link power mode. It will be understood that particular values of low battery idle timeout value and low battery LTR value may be selected for a given implementation to achieve a desired balance between conserving remaining battery capacity of battery cells167and maintaining a minimum level of I/O performance for SSD160.

As an example, in one exemplary embodiment of low battery mode PCIe link power management settings configuration employed during low battery SSD power mode operation of block408, the LTR value of SSD160may be set to “No Requirement” so that host PCIe root complex136(and hence host programmable integrated circuit110such as CPU) can go to the lowest power modes or C-states (e.g., C8, C9, C10 states). In this exemplary embodiment, the transition of the PCIe link135initiates from PCIe Specification L0 link power mode to PCIe Specification L1.0 link power mode (i.e., reduced power state but with system clock maintained on PCIe link135by host PCIe root complex136) when PCIe link135is in idle for 10 us, At this time, the clock request (CLKREQ) from SSD160to host programmable integrated circuit110is de-asserted immediately after the PCIe link135enters the PCIe Specification L1 link power mode, and then the PCIe link135transitions from PCIe Specification L1 link power mode to PCIe Specification L1.2 link power mode. At this time, host programmable integrated circuit110may save power by turning off the PCIe clock (e.g., saving 200 milliwatts) and by entering a deeper host power saving mode to save additional power, e.g., depending on type of host programmable integrated circuit110(e.g., type of CPU) and its particular host implementation.

Also in low battery SSD power mode of block408, PCIe link and NVMe power control logic160on microcontroller164causes SSD160to operate using predefined low battery mode NVMe settings by aggressively transitioning SSD160into non-operational power modes during idle time, e.g., by setting a low battery Idle Time Prior to Transit (ITPT) to a smaller (or shorter time) predefined value than a predefined normal battery ITPT value that is used during normal battery SSD power mode (the smaller the value of ITPT setting, the faster SSD160transitions from relatively higher powered Active Idle mode (e.g., 400 milliwatts) to relatively lower powered non-operational power mode (e.g., 5 milliwatts) and PCIe link135transitions to L1.2 link mode). It will be understood that a particular value of low battery ITPT value may be selected for a given implementation to achieve a desired balance between conserving remaining battery capacity of battery cells167and maintaining a minimum level of I/O performance for SSD160. For example, in one exemplary embodiment, low battery ITPT may be set to be a predefined fixed minimum allowable value during low battery SSD power mode that maximizes the power saving (i.e., minimizes power consumption) while at the same time not causing unbearable I/O latency for SSD160(e.g., such as latency that causes replay of video data from SSD160to stutter or freeze). This is in contrast to conventional implementations which employ the same fixed ITPT value for transitioning a SSD into non-operational power modes, regardless of the current amount of remaining battery capacity. Methodology400then returns from block408to block402where PCIe link and NVMe power control logic160on microcontroller164of SSD160receives the next predefined power mode command of iterative methodology300across SMBus181from EC180.

As an example, in one exemplary embodiment of low battery mode NVMe power settings configuration employed during low battery SSD power mode operation of block408, ITPT is set to the minimum allowable value (e.g., 10 milliseconds) and any dynamic adjustment of ITPT values based on workload is suspended. Then SSD160transitions as soon as possible (e.g., with a 5 milliseconds to 10 milliseconds transition time, a less than 10 milliseconds transition time, a less than 20 milliseconds transition time, etc.) from SSD non-operational NVMe Active Power (ACTP) power state (PS3 or S3) in which some SSD modules (e.g., SSD DRAM volatile memory module/s) remain powered on into deeper non-operational power saving SSD non-operational power mode NVMe ACTP power state (PS4 or S4) in which all SSD modules (e.g., including SSD DRAM volatile memory module/s) are powered off. This is in contrast to a fixed transition time of 100 milliseconds from PS3 to PS4 that is conventionally employed for SSD operation.

Returning to block404of methodology400, if the current received power mode command of block402is determined not to be an “Enter low battery SSD power mode” power mode command (i.e., the current received power mode command of block402is determined in block410to be an “Exit low battery SSD power mode” power mode command), then methodology400proceeds to block412where PCIe link and NVMe power control logic160on microcontroller164of SSD160causes SSD160to dynamically change to begin (or continue) operating in a higher SSD power mode that is relatively higher (i.e., consumes more power) than the low battery SSD power mode. In one exemplary embodiment described further below, such a relatively higher SSD power mode may be a normal (e.g., default) battery SSD power mode having normal (e.g., default) battery mode PCIe link power management settings and normal (e.g., default) battery mode NVMe power settings that, when implemented, operate to consume more power than the respective low battery mode PCIe link power management settings and low battery mode NVMe settings of block408consume when implemented during low battery SSD power mode.

After block412, methodology400proceeds to block414where SSD160operates in normal battery SSD power mode using normal battery mode PCIe link power management settings for SSD input/output (I/O). Just as an example, during normal battery SSD power mode a predefined normal battery DC mode idle timeout value or SSD self-idle timer value may be used while operating in the PCIe Specification L0 link power mode during link idle before transitioning into the PCIe Specification L1.2 link power mode. This predefined normal battery SSD self-idle timer value (e.g., 60 milliseconds) used during normal battery SSD power mode is longer than the relatively shorter SSD self-idle timer value (previously described) that is used during low battery SSD power mode while operating in the PCIe Specification L0 link power mode during link idle before moving into the PCIe Specification L1.2 link power mode. In one exemplary embodiment, the predefined normal battery SSD self-idle timer value may be selected to achieve maximum (e.g., lowest latency) I/O performance for SSD160. In one embodiment, host programmable integrated circuit110may continue to execute the host OS101and/or user application/s102during the default SSD power mode of block414, and at this time SSD160may respond to host input/output I/O data requests (i.e., host read and write requests) transmitted from the host programmable integrated circuit110during the low battery SSD power mode of block414.

Also in normal battery SSD power mode operation of block4149+, PCIe link and NVMe power control logic160on microcontroller164causes SSD160to operate using predefined normal battery mode NVMe settings that operated during idle time to transition SSD160into non-operational power modes after occurrence of a longer elapsed time than is the case when using predefined low battery mode NVMe settings of the low battery SSD mode, e.g., by setting a normal battery ITPT to a higher predefined value than the predefined low battery ITPT value that is used during low battery SSD power mode. It will be understood that in one exemplary embodiment a particular value of normal battery ITPT value may be selected for a given implementation to achieve maximum (e.g., lowest latency) I/O performance for SSD160. Once again, this is contrast to conventional implementations which employ the same fixed ITPT value for transitioning a SSD into non-operational power modes, regardless of the current amount of remaining battery capacity. Methodology400then returns from block414to block402where PCIe link and NVMe power control logic160on microcontroller164of SSD160receives the next predefined power mode command of iterative methodology300across SMBus181from EC180.

It will understood that the particular combination of blocks of methodology400is exemplary only, and that other combinations of fewer, additional and/or alternative blocks may be employed that are suitable for implementing SSD power mode in response to received power mode commands from a programmable integrated circuit that is external to the SSD.

It will also be understood that one or more of the tasks, functions, or methodologies described herein (e.g., including those described herein for components101,102,110,136,139,140,150,155,160,164,165,166,170,173,175,180,183,189,194, etc.) may be implemented by circuitry and/or by a computer program of instructions (e.g., computer readable code such as firmware code or software code) embodied in a non-transitory tangible computer readable medium (e.g., optical disk, magnetic disk, non-volatile memory device, etc.), in which the computer program includes instructions that are configured when executed on a processing device in the form of a programmable integrated circuit (e.g., processor such as CPU, controller, microcontroller, microprocessor, ASIC, etc. or programmable logic device “PLD” such as FPGA, complex programmable logic device “CPLD”, etc.) to perform one or more blocks of the methodologies disclosed herein. In one embodiment, a group of such processing devices may be selected from the group consisting of CPU, controller, microcontroller, microprocessor, FPGA, CPLD and ASIC. The computer program of instructions may include an ordered listing of executable instructions for implementing logical functions in an processing system or component thereof. The executable instructions may include a plurality of code segments operable to instruct components of an processing system to perform the methodologies disclosed herein.

It will also be understood that one or more blocks of the present methodologies may be employed in one or more code segments of the computer program. For example, a code segment executed by the information handling system may include one or more blocks of the disclosed methodologies. It will be understood that a processing device may be configured to execute or otherwise be programmed with software, firmware, logic, and/or other program instructions stored in one or more non-transitory tangible computer-readable mediums (e.g., data storage devices, flash memories, random update memories, read only memories, programmable memory devices, reprogrammable storage devices, hard drives, floppy disks, DVDs, CD-ROMs, and/or any other tangible data storage mediums) to perform the operations, tasks, functions, or actions described herein for the disclosed embodiments.

For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., personal digital assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, touch screen and/or a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.

While the invention may be adaptable to various modifications and alternative forms, specific embodiments have been shown by way of example and described herein. However, it should be understood that the invention is not intended to be limited to the particular forms disclosed. Rather, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims. Moreover, the different aspects of the disclosed systems and methods may be utilized in various combinations and/or independently. Thus the invention is not limited to only those combinations shown herein, but rather may include other combinations.