Power supply operation method of chipset and chipset

Abstract

The invention discloses a power operation method of a chipset and the chipset. A chipset holds a first hardware semaphore to indicate that a processing subsystem has turned off a power supply. The first hardware semaphore coordinates the power state between the driver and the processing subsystem. When the processing subsystem turns on the power supply, the chipset releases the first hardware semaphore. This release allows the driver to operate hardware components associated with the processing subsystem. The chipset attempts to acquire the first hardware semaphore by the processing subsystem prior to turning off the power. And the chipset turns off the power supply of the processing subsystem after successfully acquiring the first hardware semaphore.

Description

[0001] CROSS REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application Serial No. 63 / 516,560, filed on July 31, 2023, entitled “APUSYS FAST POWER ON / OFF FOR MULTI HOST,” which is expressly incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to power management in a multi-host computing environment and, more particularly, to techniques for efficiently managing power on / off states using hardware semaphores and hardware voters to reduce latency and software complexity. Background Art

[0004] In the field of mobile devices, such as smartphones, power management is a critical aspect in system design. Since these devices rely on battery power, they need to be continuously optimized for power consumption while maintaining performance. A key component in current mobile device system-on-chips (SoCs) is artificial intelligence (AI) accelerators, which are used to perform AI calculations for various applications, such as camera image processing, voice recognition, etc.

[0005] In mobile device SoCs, power management of AI accelerators (APUSYS) involves complex software-based communication between multiple drivers in a Linux environment. The power on / off process of the AI ​​accelerator requires extensive handshaking between the Linux-side power management driver and the driver on the memory management unit (MMU) side through the Linux_pm_runtime framework. This approach can cause significant delays in the power on / off process and is prone to large fluctuations due to the non-real-time nature of the Linux operating system.

[0006] In addition, there are challenges in managing the power state of multiple hosts accessing the AI ​​accelerator, such as Linux, Trusted Execution Environment (TEE), Sensor Hub Control Processor (SCP), modem, and audio. Each host requires its own power management driver, resulting in increased memory usage and development effort. The communication between these hosts and the AI ​​accelerator driver adds latency to the power on / off process.

[0007] The complex mapping between the power path and data path controllers of the memory management unit and AI accelerator hardware further complicates the power management process. The AI ​​accelerator driver controls the power of the memory management unit hardware, while the memory management unit driver controls the data path of the AI ​​accelerator. This interdependency requires extensive communication between the drivers, increasing the overall complexity of the system. Summary of the invention

[0008] The following content provides a simplified summary of one or more aspects in order to provide a basic understanding of these aspects. This summary is not a comprehensive overview of all aspects considered, nor is it intended to identify key or important elements of all aspects, nor to delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that follows.

[0009] In one aspect of the present disclosure, a method, a computer readable medium, and a device are provided. The device may be a chipset. The chipset holds a first hardware semaphore to indicate that a processing subsystem has been powered off. The first hardware semaphore coordinates the power state between a driver and the processing subsystem. When the processing subsystem is powered on, the chipset releases the first hardware semaphore. This release allows the driver to operate hardware components associated with the processing subsystem. The chipset attempts to obtain the first hardware semaphore from the processing subsystem before powering off. The chipset turns off the power of the processing subsystem after successfully acquiring the first hardware semaphore.

[0010] To achieve the above and related purposes, one or more aspects include the following features, which will be described in detail below and particularly pointed out in the claims. The following description and the accompanying drawings set forth in detail certain exemplary features of one or more aspects. However, these features are merely indicative of several ways in which the principles of the various aspects may be applied, and this description is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 Certain hardware components of a chipset of a user device (or computing device) according to a first aspect and certain software components running on the chipset are described.

[0012] Figure 2 Certain hardware components of a chipset of a user device (or computing device) according to a second aspect and certain software components running on the chipset are described.

[0013] 3(A) and 3(B) are a flow chart illustrating a power supply operation method of a chipset.

[0014] Description of Figure Numbers:

[0015] 100, 200 icons

[0016] 112MDW (Middleware) driver

[0017] 114 Memory Management Unit Driver

[0018] 116 Power Control Driver

[0019] 118 Memory Management Unit Hardware

[0020] 120 AI accelerator central control microprocessor

[0021] 210Reviser

[0022] 212MDW

[0023] 218 Other components

[0024] 222Linux Driver

[0025] 224 Components Processing IPI

[0026] 226 power control signal

[0027] 230Linux

[0028] 232TEE

[0029] 234 Modem

[0030] 236Hifi

[0031] 238SCP

[0032] 240 Control Circuit

[0033] 247 APU power control hardware

[0034] 251-1~252-5 mailbox MBOX

[0035] 270 Hardware Semaphore

[0036] 290 AI Accelerator

[0037] 300, 400 Process

[0038] Steps 302-320 DETAILED DESCRIPTION

[0039] The following detailed description is associated with the accompanying drawings and is intended to describe various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, experts in the art will appreciate that these concepts may be practiced without these specific details. In some cases, in order to avoid obscuring these concepts, known structures and components are shown in block diagram form.

[0040] Several aspects of telecommunication systems will now be described with reference to various devices and methods. These devices and methods will be described in the following detailed description and illustrated in the accompanying drawings by various modules, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented using electronic hardware, computer software, or any combination of the two. Whether these elements are implemented in hardware or software depends on the specific application and design constraints of the overall system.

[0041] For example, an element or any part of an element or any combination of elements can be implemented as a "processing system" containing one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on chips (SoCs), baseband processors, field programmable logic gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described in this disclosure. One or more processors in a processing system can execute software. Software should be broadly understood as instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, processes, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language or other.

[0042] Thus, in one or more example aspects, the functions described may be implemented in hardware, software, or any combination of the two. If implemented in software, the functions may be stored or encoded as one or more instructions or codes on a computer readable medium. Computer readable media include computer storage media. The storage medium may be any available medium that a computer can access. For example, but not limited to, such computer readable media may include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the above types of computer readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.

[0043] Figure 1 , Figure 100 illustrates certain hardware components of a chipset of a user device (or computing device) according to the first solution and certain software components running on the chipset. In this example, the UE includes the following components: an MDW (Middleware) driver 112 that receives a user's AI computing request and forwards it to the AI ​​accelerator hardware, a memory management unit driver 114 that is responsible for managing the memory management unit hardware 118 and refreshing the TLB (Translation Lookaside Buffer) table; a power control driver 116 that controls the power state of the AI ​​accelerator central control microprocessor 120; a hardware component memory management unit hardware 118 that performs virtual to physical address translation to enable the AI ​​accelerator central control microprocessor 120 to access DRAM; and an AI accelerator central control microprocessor 120 that performs AI computing.

[0044] In the first scheme, to start the UE, the MDW driver 112 sends a "mem-unmap" command to the memory management unit driver 114, which handles the memory un-imaging process. Once completed, the MDW driver 112 sends a "mem-map" command to the memory management unit driver 114 to image the memory again. Next, the MDW driver 112 issues an "execute CMD" command to the power control driver 116 to start the boot sequence of the AI ​​accelerator central control microprocessor 120. The power control driver 116 then notifies the memory management unit driver 114 to start the memory management unit hardware 118 using the Linux pm_runtime framework. The memory management unit driver 114 refreshes the TLB table in the memory management unit hardware 118. The memory management unit driver 114 confirms to the power control driver 116 through the pm_run time framework that the TLB refresh is complete. The power control driver 116 allows the AI ​​accelerator central control microprocessor 120 to start. The AI ​​accelerator central control microprocessor 120 sends an "Init Done" signal to the power control driver 116 after completing the boot process. The power control driver 116 sends "Execute CMD IPI" to the AI ​​accelerator central control microprocessor 120 to start executing AI calculations. The AI ​​accelerator central control microprocessor 120 executes the command and sends a "CMD Done IPI" signal to the power control driver 116, which in turn notifies the MDW driver 112 that the command execution is complete.

[0045] In the first scheme, in order to shut down the UE, the AI ​​accelerator central control microprocessor 120 exchanges two IPIs (Inter-Processor Interrupts) with the power control driver 116 to confirm that it can be shut down (DeepIdle1 and DeepIdle2 IPIs). The AI ​​accelerator central control microprocessor 120 starts the shutdown process and notifies the power control driver 116 after it no longer needs to access the DRAM. The power control driver 116 notifies the memory management unit driver 114 to stop accessing the memory management unit hardware 118 using the pm_runtime framework. The power control driver 116 confirms that the memory management unit driver 114 has confirmed this request through the pm_runtime framework. The power control driver 116 shuts down the AI ​​accelerator central control microprocessor 120.

[0046] In the first solution, the switching process of the AI ​​accelerator's control microprocessor 120 involves complex handover protocols and communications between the power control driver 116 and the memory management unit driver 114 through the Linux pm_runtime framework, which may introduce significant delays in the switching process.

[0047] The non-real-time nature of the Linux operating system may also cause large fluctuations in power on / off delays. In addition, during the power-off process, multiple communications are required between the AI ​​accelerator central control microprocessor 120 and the power control driver 116, which may further increase the delay. Table 1 illustrates the mapping between the memory management unit hardware 118 and the power path controller and data path controller of the AI ​​accelerator central control microprocessor 120. This mapping causes the control scenario between the memory management unit hardware 118 and the AI ​​accelerator central control microprocessor 120 to become complicated, requiring a large amount of two-way communication between the memory management unit driver 114 and the AI ​​accelerator Linux driver (power control driver 116) in the Linux environment.

[0048] Table 1 Power path and data path controllers for memory management unit hardware and AI accelerator hardware

[0049]

[0050] The power path controller of the memory management unit hardware 118 is the AI ​​accelerator Linux driver (power control driver 116), while the data path controller is the memory management unit Linux driver (memory management unit driver 114). This means that the AI ​​accelerator Linux driver controls the power of the memory management unit hardware even though it is not directly responsible for its data path. On the other hand, the AI ​​accelerator hardware (AI accelerator central control microprocessor 120) relies on the memory management unit Linux driver (memory management unit driver 114) to control its data path because it cannot control data conversion by itself. This complex mapping between the power path and data path controller requires a lot of communication between the memory management unit driver 114 and the AI ​​accelerator Linux driver (power control driver 116) in the Linux environment, resulting in increased delays and complexity in the power on / off process.

[0051] In the first scenario, multiple hosts such as Linux, TEE (non-Linux software (SW)), SCP (low-power hardware (HW)), modem (HW), and audio (HW) may use the AI ​​accelerator control processor 120 for AI computing. Some hosts, such as SCP, may use the AI ​​accelerator control processor 120's suspend mode without the need to access DRAM, while other hosts, such as modems and audio, may need to access DRAM even though they are not part of the Linux environment. This multi-host scenario introduces additional latency and complexity in the power on / off process. Non-Linux hosts face challenges when trying to turn on the AI ​​accelerator control processor 120 because they must request Linux to perform a power-on operation, which results in increased latency, or implement their own power driver within each host, which increases development effort and memory usage. In addition, non-Linux hosts that need access to DRAM must communicate with Linux and the memory management unit driver 114, which introduces additional latency. As the number of hosts increases, the power on / off process of the control processor 120 in the AI ​​accelerator becomes more and more complicated, because the power control driver 116 must communicate with each host to confirm its usage status before the power off process can be carried out. As the number of hosts increases, the delay increases rapidly.

[0052] The second solution is designed to address these challenges of the first solution. The second solution eliminates the need for communication between Linux drivers by using hardware signals to coordinate the operation of the memory management unit driver 114 at the appropriate time. The second solution simplifies the power on / off process and manages the power status of multiple hosts to avoid status errors. This can be achieved by introducing a new hardware component that manages the power on / off operations of multiple hosts simultaneously. The second solution simplifies the power on / off software process, reducing it to a single register write operation. By implementing these improvements, the complexity and delay associated with power management in a multi-host environment can be significantly reduced, resulting in faster power on / off times and improved overall system efficiency.

[0053] More specifically, the second solution eliminates the need for such software handshakes by using hardware signals to coordinate the operation of the memory management unit driver 114 at the appropriate time. This is achieved by implementing a hardware signal mechanism so that the memory management unit driver 114 only runs when the AI ​​accelerator control processor 120 is turned on. The hardware semaphore acts as a mutex, which is held by the AI ​​accelerator control processor 120 when it is turned off and released when it is turned on. This enables the memory management unit driver 114 to determine the power state of the AI ​​accelerator control processor 120 without the need for software communication. The second solution also simplifies the power on / off process by introducing a hardware voter that manages the power states of multiple hosts. Each host, such as Linux, TEE, SCP, modem, and audio, has its own mailbox (MBOX) hardware, which includes a power on / off register. The hardware semaphore must be acquired before the host operates its power on / off register. This prevents multiple hosts from making state changes at the same time and avoids state errors. As described below, the hardware voter collects the power on / off status of all MBOX power on / off registers and determines the overall power status of the AI ​​accelerator control processor 120. It decides whether to turn on or off the AI ​​accelerator control processor 120, and whether to switch between normal and low power modes. This hardware-based approach reduces the complexity of the power on / off process and minimizes the need for software communication.

[0054] The second option may provide several benefits:

[0055] Stable and fast power on / off times: By eliminating software handshaking and using hardware signaling, power on / off times are more stable and significantly faster. Power on time is reduced from 2,160μs to 880μs, and power off time is reduced from 1,800μs to 530μs.

[0056] Fewer software module dependencies: Fewer dependencies on multiple software modules lead to fewer issues and easier maintenance.

[0057] Reduced software development effort: The need for extensive software communication is minimized, reducing the development effort required to implement and maintain a power management system.

[0058] Figure 2 Certain hardware components of a chipset of a user equipment (or computing device) according to a second solution and certain software components running on the chipset are described. The UE includes, among other components, a hardware semaphore 270 for coordinating power states between a memory management unit Linux driver 222 and an AI accelerator 290; a hardware voter (control circuit 240) and mailbox (MBOX 252-1 to 252-5) mechanism for managing power states of multiple hosts (Linux 230, TEE 232, modem 234, Hifi 236, and SCP 238); and APU power control hardware 247 for handling power state transitions and interrupts.

[0059] The hardware semaphore 270 is used to coordinate the power state between the memory management unit Linux driver 222 and the AI ​​accelerator 290. By default, the hardware semaphore 270 is held, indicating that the AI ​​accelerator 290 is powered off. When the AI ​​accelerator 290 is powered on, the hardware semaphore 270 is released, allowing the memory management unit Linux driver 222 to operate the memory management unit hardware 272. Before turning off the power, the AI ​​accelerator 290 must continuously try to acquire the hardware semaphore 270 until it succeeds, ensuring that the memory management unit Linux driver 222 does not access the memory management unit hardware 272 during the power off process.

[0060] The hardware voter (control circuit 240) and mailbox mechanism are used to manage the power state of multiple hosts. Each host (Linux 230, TEE 232, modem 234, Hifi 236, and SCP 238) has its own MBOX (252-1 to 252-5), which includes a power on / off register. To change the power state, the host must first acquire the hardware semaphore 280, preventing multiple hosts from changing the state at the same time. Once the hardware semaphore 280 is acquired, the host can write to its power on / off register to request to turn the power on or off.

[0061] The control circuit 240 collects the power on / off status of all MBOX power on / off registers and determines the overall power state of the AI ​​accelerator 290. It decides whether to turn on or off the AI ​​accelerator 290, and whether to switch between normal and low power modes. The APU power control hardware 247 handles the actual power state transition and generates an interrupt to notify the host of the current power state.

[0062] This hardware-based approach simplifies the power on / off process and reduces the need for complex software communication between the host and the AI ​​accelerator 290. By using hardware semaphores 280 and a hardware voting mechanism, the proposed solution achieves faster and more stable power on / off times while minimizing software complexity and development effort.

[0063] In the proposed solution, the Reviser 210 and MDW 212 components handle the D-Time (dynamic time) of the IPI 224 and power control signals 226, which are used to control the power state and communicate with the Linux 230 host. Other components 218 in the system can also interact with the power management mechanism as needed.

[0064] The second approach solves the latency and complexity issues associated with multi-host power on / off scenarios by eliminating or reducing the need for complex software handshaking and introducing a hardware-based power state coordination and management mechanism, thereby improving system performance and reducing development effort.

[0065] As described above, the hardware semaphore 270 coordinates the power state between the memory management unit Linux driver 222 and the AI ​​accelerator 290. This hardware semaphore acts as a mutex lock. The memory management unit Linux driver 222 and the AI ​​accelerator 290 operate in a mutually exclusive manner, preventing unexpected operations from occurring during power state transitions.

[0066] By default, when the UE is powered on, the hardware semaphore 270 is held, indicating that the AI ​​accelerator 290 is powered off. In this state, no entity can acquire the semaphore. When the AI ​​accelerator 290 is powered on, it releases the hardware semaphore 270, allowing the memory management unit Linux driver 222 to acquire it and perform necessary operations on the memory management unit hardware 272.

[0067] When the memory management unit Linux driver 222 needs to update the mapping between physical addresses and virtual addresses in the memory management unit hardware 272, it first attempts to obtain the hardware semaphore 270. If the semaphore cannot be obtained, it means that the AI ​​accelerator 290 is powered off and no update is required. However, if the semaphore is successfully obtained, it is confirmed that the AI ​​accelerator 290 is powered on, and the memory management unit Linux driver 222 can continue to update the mapping and translation table in the memory management unit hardware 272.

[0068] During the power-off process, the AI ​​accelerator 290 continuously attempts to acquire the hardware semaphore 270. If the semaphore is successfully acquired, it means that the memory management unit Linux driver 222 is not running on the memory management unit hardware 272, and the AI ​​accelerator 290 can be safely powered off. Once the AI ​​accelerator 290 is powered off, the memory management unit Linux driver 222 will not be able to acquire the semaphore, preventing any unexpected operations on the memory management unit hardware 272.

[0069] This hardware semaphore mechanism simplifies the complex communication between the memory management unit Linux driver 222 and the AI ​​accelerator 290 in the Linux environment. The memory management unit Linux driver 222 can determine the power state of the AI ​​accelerator 290 by simply trying to obtain the hardware semaphore 270, eliminating the need for complex software handshakes. Similarly, the AI ​​accelerator 290 can control the memory management unit Linux driver 222's access to the memory management unit hardware 272 through the hardware semaphore 270. Both entities operate at the correct time, avoiding any unexpected operations.

[0070] The hardware semaphore 270 is implemented as a hardware component within the UE's system-on-chip (SoC). It is part of the main CPU and can be accessed by both the memory management unit Linux driver 222 and the AI ​​accelerator 290.

[0071] The second scheme uses a hardware-based mechanism to manage the power on / off status of multiple hosts accessing the AI ​​accelerator 290. The mechanism includes a hardware voter (control circuit 240) and a mailbox (MBOX) mechanism, and each host (Linux 230, TEE 232, modem 234, Hifi 236, and SCP 238) has an MB OX (MBOX 252-1 to 252-5).

[0072] Each host is assigned its own MBOX hardware, which contains a power on / off register. The power on / off register contains two bits: one for normal power mode and the other for pause mode. To change the power state of the AI ​​accelerator 290, the host must first acquire a hardware semaphore (hardware semaphore) 280. Only one host can access the power on / off register at a time, thereby preventing conflicts and inconsistencies in power states.

[0073] Once the host acquires the hardware semaphore 280, it can write to its power on / off register to request a power on or off operation. The control circuit 240 (hardware voter) collects the power on / off status of all MBOX power on / off registers and determines the overall power state of the AI ​​accelerator 290.

[0074] The control circuit 240 decides whether to turn on or off the power of the AI ​​accelerator 290 based on the collective power on / off request of all hosts. It also decides whether the AI ​​accelerator 290 should operate in normal power mode or suspended power mode. If the power mode changes (e.g., from normal power to suspended power or vice versa), the control circuit 240 initiates the necessary power mode switching sequence.

[0075] The APU power control hardware 247 assists with power state transitions and generates interrupts to inform the host AI accelerator 290 of the current power state.

[0076] For example, when the modem 234 host wants to turn the AI ​​accelerator 290 on or off, it must first acquire the hardware semaphore 280. Once the modem 234 host acquires the hardware semaphore 280, other hosts cannot acquire it. At this point, the modem 234 host can write to its power on / off register (Reg 250-3) to indicate its intention to turn the AI ​​accelerator 290 on or off.

[0077] The control circuit 240 (hardware voter) collects the power on / off status of all MBOX power on / off registers and determines the overall power state of the AI ​​accelerator 290. It decides whether to turn on or off the power of the AI ​​accelerator 290 based on the collective power on / off requests of all hosts. The control circuit 240 also decides whether the AI ​​accelerator 290 should operate in normal power mode or suspend power mode, and initiates the necessary power mode switching sequence if necessary.

[0078] Hardware semaphore 280 ensures that power state transitions are atomic operations, preventing race conditions and inconsistencies. Control circuit 240 simplifies the decision-making process for power on / off states and power mode transitions, reducing the delay and overhead associated with software coordination.

[0079] Some hosts, such as SCP 238, operate in low power mode and do not need access to DRAM. Other hosts, including Linux 230, TEE 232, modem 234, and Hifi 236, operate in normal power mode and need access to DRAM.

[0080] The control circuit 240 (hardware voter) distinguishes between normal power and low power mode requests from the host. When the host requests an on or off power operation, the control circuit 240 determines the appropriate power mode based on the collective power mode request of all MBOX power on / off registers.

[0081] In the case of a power mode transition, such as from low power to normal power (Low→Nor PWR) or from normal power to low power (Nor→Low PWR), the APU power control hardware 247 generates the necessary control signals to manage DRAM access through the hardware semaphore 270 and the MMU hardware 272.

[0082] For example, when transitioning from low power mode to normal power mode, the AI ​​accelerator 290 must relinquish control of the hardware semaphore 270 and the memory management unit hardware 272 to enable DRAM access for the host running in normal power mode. Similarly, when transitioning from normal power mode to low power mode, the AI ​​accelerator 290 must acquire control of the hardware semaphore 270 and the memory management unit hardware 272 to prevent DRAM access because the host in low power mode does not need it.

[0083] Therefore, the AI ​​accelerator 290 operates in the appropriate power mode and grants DRAM access only to the hosts that need it. This approach minimizes power consumption while maintaining the required functionality for each host.

[0084] 3(A) and 3(B) are flow charts 300 of a method for chipset power operation. The method may be performed by a chipset (e.g., Figure 2 The chipset described herein is executed. In operation 302, the chipset holds a first hardware semaphore to indicate that the processing subsystem has been powered off. The first hardware semaphore coordinates the power state between the driver and the processing subsystem. In operation 304, when the processing subsystem is powered on, the chipset releases the first hardware semaphore to allow the driver to operate the hardware components related to the processing subsystem. In operation 306, the processing subsystem attempts to acquire the first hardware semaphore before turning off the power. In operation 308, the chipset turns off the power of the processing subsystem after successfully acquiring the first hardware semaphore.

[0085] In some configurations, the driver is a memory management unit (MMU) driver and the hardware component is a memory management unit (MMU). In some configurations, the processing subsystem is an artificial intelligence (AI) processing subsystem.

[0086] In operation 310, a host in the plurality of hosts obtains a second hardware semaphore before writing a corresponding power state register in the plurality of power state registers. In operation 312, the chipset collects power states from the plurality of power state registers. In operation 314, the chipset determines an overall power state of the processing subsystem based on the collected power states.

[0087] In operation 316, the chipset maintains or changes the power state of the processing subsystem according to the collected power state. In operation 318, the chipset determines whether the processing subsystem should operate in a normal power mode or a low power mode according to the collected power state.

[0088] In operation 320, when the power mode of the processing subsystem changes, the chipset initiates a power mode switching sequence. In some configurations, the power mode switching sequence includes transitioning from a low power mode to a normal power mode and relinquishing control of a first hardware semaphore and a hardware component to allow a host running in a normal power mode to access memory. In some configurations, the power mode switching sequence includes transitioning from a normal power mode to a low power mode and acquiring control of a first hardware semaphore and a hardware component to prevent a host running in a low power mode from accessing memory.

[0089] In some configurations, the plurality of hosts includes at least one Linux host, a trusted execution environment (TEE) host, a modem host, an audio host, and a SensorHub Control Processor (SCP) host.

[0090] It should be understood that the specific order or hierarchy in the disclosed processes / flowcharts is an illustration of exemplary methods. Based on design preferences, it should be understood that the specific order or hierarchy in the processes / flowcharts can be rearranged. In addition, some blocks can be combined or omitted. The accompanying method claims present elements of the various blocks in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0091] The foregoing description is intended to enable a person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to a person skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but should be consistent with the full scope of the language claims, where reference to a singular element does not mean "only one", unless specifically stated, but refers to "one or more". The word "exemplary" used herein means "as an example, instance or illustration". Any aspect described herein as "exemplary" is not necessarily interpreted as being superior to other aspects. Unless specifically stated otherwise, the word "some" refers to one or more. Combinations such as "at least one A, B or C", "one or more A, B or C", "at least one A, B and C", "one or more A, B and C", and "A, B, C or any combination thereof" include any combination of A, B and / or C, and may include multiple A, multiple B or multiple C. Specifically, combinations such as "at least one A, B, or C," "one or more A, B, or C," "at least one A, B and C," "one or more A, B, and C," and "A, B, C, or any combination thereof" may be only A, only B, only C, A and B, A and C, B and C, or A and B and C, wherein any such combination may contain one or more members of A, B, or C. All structural and functional equivalents to the various aspects described herein, which are known or later known to one of ordinary skill in the art, are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be disclosed, whether or not expressly stated in the claims. The words "module," "mechanism," "element," "device," and the like may not be substitutes for the word "means." Therefore, no claim element should be interpreted as means plus function unless the element is expressly stated using the word "means."

Claims

1. A chipset power operation method, characterized in that: The method includes: Maintaining a first hardware semaphore to indicate that the processing subsystem has been powered off, wherein the first hardware semaphore coordinates a power state between a driver and the processing subsystem; releasing the first hardware semaphore when the processing subsystem is powered on to allow the driver to operate a hardware component associated with the processing subsystem; Before turning off the power, the processing subsystem attempts to acquire the first hardware semaphore; and The processing subsystem is powered off after successfully acquiring the first hardware semaphore.

2. The method according to claim 1, characterized in that The driver is a memory management unit driver and the hardware component is a memory management unit.

3. The method according to claim 1, characterized in that The processing subsystem is an artificial intelligence processing subsystem.

4. The method according to claim 1, characterized in that Further including: Before writing the corresponding plurality of power status registers, a host among the plurality of hosts obtains a second hardware semaphore; Collect power status from multiple power status registers; as well as An overall power state of the processing subsystem is determined based on the collected multiple power states.

5. The method according to claim 4, characterized in that Further including: A power state of the processing subsystem is maintained or changed based on the collected plurality of power states.

6. The method according to claim 4, characterized in that Determining an overall power state of the processing subsystem includes determining whether the processing subsystem should operate in a normal power mode or a low power mode based on the collected plurality of power states.

7. The method according to claim 6, characterized in that Further including: When the power mode of the processing subsystem is changed, a power mode switching sequence is initiated.

8. The method according to claim 7, characterized in that The power mode switching sequence includes: Transitioning from low power mode to normal power mode; and Control of the first hardware semaphore and the hardware component is relinquished so that a host operating in a normal power mode can access the memory.

9. The method according to claim 7, characterized in that The power mode switching sequence includes: Transitioning from normal power mode to low power mode; and Control of a first hardware semaphore and a hardware component is obtained to prevent a host operating in a low power mode from accessing memory.

10. The method according to claim 4, characterized in that The multiple hosts include at least one Linux host, a trusted execution environment host, a modem host, an audio host, and a SensorHub control processor host.

11. A chipset, characterized in that: include: a processing subsystem; A driver associated with a hardware component of the processing subsystem; a first hardware semaphore for coordinating power states between the driver and the processing subsystem, wherein the first hardware semaphore is held when the processing subsystem is powered off and released when the processing subsystem is powered on to allow the driver to operate the hardware component; and A power management unit configured to: Attempting to acquire a first hardware semaphore before shutting down power to the processing subsystem; as well as The processing subsystem is powered off after successfully acquiring the first hardware semaphore.

12. The chipset according to claim 11, wherein: The driver is a memory management unit driver and the hardware component is a memory management unit.

13. The chipset according to claim 11, wherein: The processing subsystem is an artificial intelligence processing subsystem.

14. The chipset according to claim 11, wherein: Further including: a plurality of power status registers, each associated with a corresponding host among the plurality of hosts; a second hardware semaphore; as well as A hardware voter, configured as: Collect power status from multiple power status registers; as well as determining an overall power state of a processing subsystem based on the collected multiple power states; Each of the plurality of hosts is configured to obtain a second hardware semaphore before writing into its corresponding power status register.

15. The chipset according to claim 14, wherein: The power management unit is further configured as: A power state of the processing subsystem is maintained or changed based on the collected plurality of power states.

16. The chipset according to claim 14, wherein: To determine the overall power state of the processing subsystem, the hardware voter is configured to decide whether the processing subsystem operates in a normal power mode or a low power mode according to the collected multiple power states.

17. The chipset according to claim 16, wherein: Further included is a power mode switching unit configured to initiate a power mode switching sequence when the power mode of the processing subsystem changes.

18. The chipset according to claim 17, wherein: The power mode switching unit is configured to, when transitioning from a low power mode to a normal power mode: Control of the first hardware semaphore and the hardware component is relinquished so that a host operating in a normal power mode can access the memory.

19. The chipset according to claim 17, wherein: The power mode switching unit is configured to, when transitioning from a normal power mode to a low power mode: Control of a first hardware semaphore and a hardware component is obtained to prevent a host operating in a low power mode from accessing memory.

20. The chipset according to claim 14, wherein: The multiple hosts include at least one Linux host, a trusted execution environment host, a modem host, an audio host, and a SensorHub control processor host.

Images