WO2013182098A1

WO2013182098A1 - Method and device for multicore terminal sharing resources

Info

Publication number: WO2013182098A1
Application number: PCT/CN2013/078108
Authority: WO
Inventors: 张映俊; 丁克忠; 吴敏锋
Original assignee: 中兴通讯股份有限公司
Priority date: 2012-10-25
Filing date: 2013-06-27
Publication date: 2013-12-12
Also published as: CN103778014A

Abstract

Embodiments of the present invention relate to a method and a device for a multicore terminal sharing resources. The method comprises: when one core in the multicore terminal needs to share the resources, reading a status bit of a shared mutex register; when the status bit of the shared mutex register is idle, setting a corresponding parameter according to information stored by the shared mutex register to perform resource sharing. According to the embodiments of the present invention, when the multicore terminal has multiple shared resources currently, the shared mutex register is used to protect and coordinate a use of the shared resources, therefore coordinating allocation of the shared resources performed by the cores, which improves a use rate of public resources, and meanwhile, improves overall performance of a terminal system.

Description

Method and device for sharing resources by multi-core terminal

The present invention relates to the field of mobile communication technologies, and in particular, to a method and apparatus for sharing resources by a multi-core terminal.

Background technique

With the rapid development of system integration technology and wireless communication technology, especially in wireless communication systems, a large number of multi-core intelligent machine terminals have appeared, resulting in conflicts between CPU cores when operating many common resources. For example, when a CPU core needs to adjust the system bus frequency or core voltage, it will affect the performance of other cores. If the CPU cores perform frequency modulation and voltage regulation at the same time, conflicts will occur; for example, when a certain CPU core needs to operate publicly. When the RF (radio frequency) resource affects the functions of other cores, if the CPU cores operate the common RF resources at the same time, the resource usage conflict will also occur. For other public resources, there are also conflicts. Summary of the invention

Embodiments of the present invention provide a method and an apparatus for sharing resources by a multi-core terminal, which are intended to implement protection and coordinated use of public resources.

The method for sharing resources by the multi-core terminal includes:

When one of the cores of the multi-core terminal needs to operate the shared resource, the status bit of the shared mutex register is read;

When the status bit of the shared mutex register is idle, the shared resource parameter is set according to the information stored in the shared mutex register for resource sharing.

Preferably, the shared resource includes at least one of the following: a multi-core frequency modulation, a radio frequency (RF) common resource, an I2C bus, and a universal asynchronous transceiver transmitter (UART) serial port.

Preferably, the multi-core terminal includes a first core and a second core. When the first core needs to perform frequency modulation and voltage regulation, the step of setting the shared resource parameter according to the information stored in the shared mutual exclusion register includes: Setting a status bit of the shared mutex register to a non-idle state;

Reading a current frequency of the first core from the shared mutex register, and comparing with a pre-adjusted core frequency;

Setting a current core voltage and a current frequency of the first core according to the comparison result;

Writing the current core voltage, the current frequency of the first core, and the minimum core voltage allowed by the first core into the shared mutex register, respectively.

Preferably, the step of setting the current core voltage and the current frequency of the first core according to the comparison result comprises:

When the pre-adjusted core frequency is greater than a current frequency of the first core, reading a current core voltage from the shared mutually exclusive register, and comparing with a pre-adjusted core voltage;

Reading the core voltage allowed by the second core from the shared mutual exclusion register when the pre-adjusted core voltage is greater than the current core voltage; taking the pre-adjusted core voltage and the nuclear voltage allowed by the second core The larger one is set to the current core voltage; the current frequency of the first core is set;

When the pre-adjusted core frequency is less than a current frequency of the first core, setting a current frequency of the first core; reading a current core voltage from the shared mutex register, and comparing with a pre-adjusted core voltage; Reading the core voltage allowed by the second core from the shared mutual exclusion register when the pre-adjusted core voltage is greater than the current core voltage; taking the pre-adjusted core voltage and the nuclear voltage allowed by the second core The larger one is set to the current core voltage.

Preferably, the multi-core terminal includes a first core and a second core. When the first core needs to adjust the system bus frequency, the step of setting the shared resource parameter according to the information stored in the shared mutex register includes:

Setting a status bit of the shared mutex register to a non-idle state;

Reading a current bus frequency of the system from the shared mutex register, and a minimum system bus frequency allowed by the second core;

Comparing the pre-adjusted core frequency, the current bus frequency of the system, and the lowest system bus frequency allowed by the second core; taking the largest one is set to the current bus frequency of the system;

The current bus frequency of the system and the lowest system bus frequency allowed by the second core are respectively written into the shared mutex register. Preferably, when the multi-core terminal shares the RF common resource, the step of setting the shared resource parameter according to the information stored in the shared mutex register includes:

Reading an RF common resource state from the shared mutual exclusion register when any one of the multi-core terminals is in a sleep state; if the RF common resource state is an active state, the RF common resource status is Set to a power saving state, and write the current state of the RF common resource into the mutually exclusive shared register;

Reading an RF common resource status from the shared mutex register when any of the multi-core terminals is awake; and restoring the RF common resource status if the RF common resource status is a power saving state Go to the working state and write the current state of the RF common resource to the mutually exclusive shared register.

Preferably, the above method further includes:

After the resource sharing is completed, the status bit of the shared mutex register is returned to the idle state. A device for sharing resources by a multi-core terminal, comprising:

a status bit reading module configured to: read a status bit of the shared mutex register when one of the cores of the multi-core terminal needs to operate the shared resource;

The resource sharing module is configured to: when the status bit of the shared mutex register is idle, set the shared resource parameter according to the information stored in the shared mutex register for resource sharing.

Preferably, the multi-core terminal includes a first core and a second core, and when the first core needs to perform frequency modulation and voltage regulation, the resource sharing module includes:

a setting unit configured to set a status bit of the shared mutex register to a non-idle state; a reading unit configured to read a current frequency of the first core from the shared mutex register, and Pre-adjust the nuclear frequencies for comparison;

a setting unit configured to set a current core voltage and a current frequency of the first core according to the comparison result;

An update unit configured to set the current core voltage, a current frequency of the first core, and The minimum core voltage allowed by the first core is written into the shared mutex register, respectively.

Preferably, the setting unit is further configured to: when the pre-adjusted core frequency is greater than a current frequency of the first core, read a current core voltage from the shared mutual exclusion register, and compare with a preset nuclear voltage; Reading the core voltage allowed by the second core from the shared mutual exclusion register when the pre-adjusted core voltage is greater than the current core voltage; taking the pre-adjusted core voltage and the nuclear voltage allowed by the second core The larger one is set to the current core voltage; the current frequency of the first core is set; when the pre-adjusted kernel frequency is less than the current frequency of the first core, the current frequency of the first core is set; The shared mutex register reads the current core voltage and compares with the pre-adjusted core voltage; when the pre-adjusted core voltage is greater than the current core voltage, reads from the shared mutex register that the second core allows The core voltage; the larger of the pre-adjusted core voltage and the core voltage allowed by the second core is set as the current core voltage.

Preferably, the multi-core terminal includes a first core and a second core, and when the first core needs to adjust a system bus frequency, the resource sharing module includes:

a setting unit configured to set a status bit of the shared mutex register to a non-idle state; a reading unit configured to: read a current bus frequency of the system from the shared mutex register, the second The minimum system bus frequency allowed by the core;

a setting unit, configured to: compare a preset core frequency, a current bus frequency of the system, and a minimum system bus frequency allowed by the second core; wherein the largest one is set to the current bus frequency of the system; and the update unit is set to: The current bus frequency of the system and the lowest system bus frequency allowed by the second core are respectively written into the shared mutex register.

Preferably, the multi-core terminal includes a first core and a second core. When the multi-core terminal shares the RF common resource, the resource sharing module includes: a reading unit, configured to: Reading a RF common resource status from the shared mutex register when a core wants to enter a sleep state or when waking up;

The setting unit is configured to: when any one of the multi-core terminals wants to enter a sleep state and the RF common resource state is an active state, setting the RF common resource state to a power-saving state; or Retrieving the RF common resource state to an active state when any of the multi-core terminals is awake and the common resource state is a power-saving state;

The update unit is configured to: write a current state of the RF common resource to the mutual Rejected in the shared register.

Preferably, the setting unit is further configured to: when the resource sharing is completed, return the status bit of the shared mutex register to an idle state.

A method and device for sharing resources by a multi-core terminal according to an embodiment of the present invention, for a multi-core terminal, when there are multiple shared resources, the shared mutual exclusion register is used to protect and coordinate the use of shared resources, thereby coordinating each Checking the allocation of shared resources improves the utilization of public resources and improves the overall performance of the terminal system. BRIEF abstract

1 is a schematic flowchart of a method for sharing resources of a multi-core terminal according to an embodiment of the present invention; FIG. 2 is a schematic structural diagram of an apparatus for sharing resources of a multi-core terminal according to the present invention; Schematic diagram of the structure of the resource sharing module. Preferred embodiment of the invention

The solution of the embodiment of the present invention is mainly: For a multi-core terminal, when there are multiple shared resources, the shared mutual exclusion register is used to protect and coordinate the use of the shared resource.

The multi-core terminal in the embodiment of the present invention refers to a terminal that includes two or more CPU cores (hereinafter referred to as a core). The following embodiments are described by taking the terminal of the current dual-core shared architecture as an example.

As shown in FIG. 1, an embodiment of the present invention provides a method for sharing resources by a multi-core terminal, including: Step S101: When one of the cores of the multi-core terminal needs to share resources, read a status bit of the shared mutual exclusion register;

Among them, shared resources refer to resources that can be accessed and operated by each core, including bus, memory, and peripherals, including but not limited to multi-core FM, RF common resources, I2C bus, and UART serial port.

When a core in a multi-core terminal requires operating system bus frequency or common resources such as nuclear voltage, RF resources, and public I2C bus, it will affect the performance of other cores, so when any of the core dynamics When operating public resources, it is necessary to adjust the parameters and requirements of the other party. In addition, it is necessary to avoid conflicts caused by the simultaneous operation of resources by both parties.

This embodiment utilizes a shared mutex register to protect and coordinate the use of shared resources to ensure that each core can use shared resources normally.

First, you need to design a top-level shared mutex register. The shared mutex register can be a 32-bit register, the lowest bit indicates the status bit, and the other 31 bits can be used by multiple cores.

When one of the cores of the multi-core terminal needs to use the shared resource, the status bit of the shared mutex register is read to set the corresponding parameter according to the status bit of the shared mutex register.

Step S102: When the status bit of the shared mutex register is idle, set the corresponding parameter according to the information stored in the shared mutex register for resource sharing.

Determining whether the status bit of the shared mutex register is idle, when the status bit of the shared mutex register is not idle, indicating that the peer has control over the shared resource, and the current core cannot use the resource; when the shared mutex register is When the status bit is idle, the corresponding parameters can be adjusted according to the information stored in the shared mutex register to implement resource sharing. When setting parameters, you need to set the status bit of the shared mutex register to non-idle state. After the resources are shared, you need to return the status bit of the shared mutex register to the idle state.

The following is a detailed description of the scheme for resource sharing based on multi-core terminals in this embodiment by taking multi-core FM voltage regulation, RF common resources, and I2C bus as examples:

Example 1: Application scenario for multi-core dynamic frequency modulation and voltage regulation:

First, you need to design a top-level shared mutex register to implement multi-core shared common resources using the shared mutex register.

The shared mutex register is a 32-bit register, the lowest bit indicates the status bit, and the other 31 bits can be used by the dual core. When one of the cores performs FM voltage regulation, the lowest bit of the shared mutex register is read first. When the lowest bit of the shared mutex register read is idle, the corresponding frequency and core voltage settings can be performed. Otherwise, , need to wait for the lowest bit of the shared mutex register to be idle. Of course, when setting the frequency, voltage, etc., it is necessary to rely on the information stored in the shared mutex register as the condition of the FM voltage regulation, in order to finally set the FM voltage regulation, when the frequency modulation is completed. After that, the lowest bit of the shared mutex register needs to be set to 0, and the control right is released, and the other party can use it. Wherein, the two cores in the multi-core terminal are respectively set as the first core and the second core, and the implementation process of dynamically adjusting the clock and voltage of the multi-core shared architecture is as follows:

1) When the first core needs to perform frequency modulation according to the CPU load or the application scenario mode, the lowest bit [0] of the shared mutex register is read first, and when bit [0] is 0, the sharing is indicated. The mutex register is idle and can be used at present; when bit[0] is read as 1, the shared mutex register cannot be used;

2), when the bit[0] bit is read as idle, the hardware will automatically set the bit to 1 to indicate that the shared mutex register is now used. At this time, other users are prohibited from overwriting the shared mutex register.

3) reading bit [3-l] in the shared mutex register, reading the current frequency of the first core, comparing with the pre-adjusted core frequency, and setting the current core voltage and the current frequency of the first core according to the comparison result;

If the pre-adjusted core frequency is greater than the current frequency of the first core, the up-sequence process is followed; otherwise, the entire up-conversion process is exited;

In the up-conversion process, the bit [5-4] in the shared mutex register is read, the current core voltage is obtained, and the pre-adjusted core voltage is compared with the current core voltage. If the pre-adjusted core voltage is greater than the current core voltage, Take the boost process, otherwise exit the boost process.

When the pre-adjusted core voltage is greater than the current core voltage, reading a bit [7-6] of the shared mutex register, acquiring a core voltage allowed by the second core; taking the pre-adjusted core voltage and the first The larger of the core voltages allowed by the second core is set to the current core voltage; then the current frequency of the first core is set.

In the frequency down process, the pre-adjusted core frequency is less than the current frequency of the first core, first setting a current frequency of the first core; then reading the current core voltage from the shared mutex register, and pre-adjusting The core voltage is compared; when the pre-adjusted core voltage is greater than the current core voltage, the core voltage allowed by the second core is read from a bit [7-6] of the shared mutually exclusive register; The larger of the nucleation voltage and the nuclear voltage allowed by the second core is set to the current core voltage.

Finally, the current core voltage, the current frequency of the first core, and the minimum core voltage allowed by the first core are respectively written into corresponding bit bits [5-4] and bit[3 in the shared mutual exclusion register. -l], bit[9-8].

At this point, the system sets the shared mutex register bit[0] to 0, giving up control. The implementation process of dynamically adjusting the system bus frequency corresponding to the multi-core shared architecture is as follows:

1) When the first core needs to adjust the bus frequency according to the CPU load or the application scenario mode, the lowest bit [0] of the shared mutex register is read first, and when it is read as 0, the shared mutex register is indicated. Idle, currently available; otherwise the shared mutex register cannot be used.

2), when the bit[0] bit is read as idle, the hardware will automatically set the bit to 1 to indicate that the shared mutex register is now used. At this time, other users are prohibited from overwriting the register.

3). Taking the system bus frequency dynamically as an example, when the frequency modulation strategy needs to be down-converted, the bit [13-ll] in the shared mutex register is read, and the current bus frequency of the system and the second core are allowed. Minimum system bus frequency;

Read the bit [16-14] of the shared mutex register to obtain the lowest system bus frequency allowed by the second core, and take MAX (pre-tuning the core frequency, the current bus frequency of the system, the lowest bus frequency allowed by the second core), and set The current bus frequency of the system.

Write the current system bus frequency and the lowest system bus frequency allowed by the current second core to the bit [13-ll] and bit [19-17] in the shared mutex register; afterwards, the system shares the shared mutex register bit [ 0] is set to 0, giving up control.

Example 2: Application scenario corresponding to the use of RF common resources by multiple cores:

First, a top-level shared mutex register needs to be designed to implement multi-core shared resources by using the shared mutex register. The shared mutex register is a 32-bit register, the lowest bit indicates the status bit, and the other 31 bits can be used for the dual core. When one of the cores needs to operate the RF resource, the lowest bit of the shared mutex register is read first. When the lowest bit of the shared mutex register read is idle, the corresponding RF resource operation and setting can be performed. When the lowest bit of the shared mutex register is not idle, it needs to wait for the bit to be idle. Of course, when performing RF resource operations, it is necessary to rely on the information stored in the shared mutex register as a condition for whether the RF can be operated, in order to finally perform true RF setting. When the operation is completed, the lowest bit of the shared mutex register needs to be set to 0, release control, the other party can use.

The implementation process of multi-core shared RF public resource usage is as follows: 1) When any core goes to sleep to operate the common resource to enter the power-saving state, the RF mutex shared register status bit must be read first, and must wait until bit[0] is 0. At this time, read the RF mutex shared register. The other party's core RF common resource status bit[l], if it is 0, the corresponding RF common resource is set to the power saving state, and then the current state is set to the corresponding bit of the RF mutual exclusion shared register, and finally the RF mutual exclusion sharing is configured. Register status bit bit[0] is 0, releasing control right;

2) When any core wakes up, it needs to read the RF mutex shared register status bit first. It must wait until bit[0] is 0. At this time, read the RF core common resource status bit in the RF mutex shared register. l], if it is 0, the corresponding RF common resource is restored to the working state, then the current state is set to the corresponding bit of the RF mutex shared register, and finally the RF mutex shared register status bit bit[0] is configured as 0, release control.

Example 3: Application scenario corresponding to the use of common 12 C bus resources by multiple cores:

First, you need to design a shared mutex register from the top layer. Using the shared mutex register, this register is a 32-bit register, the lowest bit indicates the status bit, and the other 31 bits can be used for the dual core. When one of the cores needs to operate the common I2C resource, the lowest bit of the shared mutex register is read first. When the read is idle, the common I2C bus can be used. When the read is non-idle, it needs to wait for the The bit is idle. When the operation is completed, the lowest bit of the shared mutex register needs to be set to 0, and the control right is released, and the other party can use it.

The implementation process of multi-core public I2C bus resource usage is as follows:

1), when any core to operate the common I2C bus resources, you must first read the I2C bus mutual exclusion shared register status bit, you must wait until bit[0] is 0, then you can operate the I2C bus resource; if bit[0] ] - straight to 1, the I2C bus cannot be operated;

2) When any core operates the I2C bus, the I2C bus mutual exclusion shared register status bit, bit[0], must be set to 1 to release control so that other cores can use the common resource.

Through the foregoing solution, the embodiment can solve the allocation and use of the multi-core shared architecture/shared resources, and can not only effectively solve the use of the public resource UART serial port, the RF resource, etc., but also can solve the multi-core DVFS frequency modulation and voltage adjustment implementation scheme, thereby improving the scheme. The overall performance of the terminal has a significant effect. For example, solving the multi-core shared architecture for dynamic frequency modulation and voltage regulation can significantly improve the standby of the system. Power consumption in scenarios such as calls and Internet access, extending the user's time spent on the battery.

In other embodiments, the implementation of the dual-core or more-core shared architecture/shared resource is implemented by using the shared mutual exclusion register, and the implementation may be extended based on the foregoing solution of the embodiment, and details are not described herein again.

As shown in FIG. 2, an embodiment of the present invention provides a device for sharing resources by a multi-core terminal, including: a status bit reading module 201 and a resource sharing module 202, where:

The status bit reading module 201 is configured to read a status bit of the shared mutex register when one of the cores of the multi-core terminal needs to share resources;

The resource sharing module 202 is configured to: when the status bit of the shared mutex register is idle, set corresponding parameters according to the information stored in the shared mutex register for resource sharing.

When a core of a multi-core terminal requires operating system bus frequency or common resources such as nuclear voltage, RF resources, and public I2C bus, it will affect the performance of other cores. Therefore, when any core dynamically operates a common resource, it needs to combine the other parameters. And the requirements are adjusted. In addition, it is necessary to avoid conflicts caused by the simultaneous operation of resources by both parties.

First, you need to design a shared mutex register from the top layer. The shared mutex register is a 32-bit register. The lowest bit indicates the status bit. The other 31 bits can be used by the dual core.

When one of the cores of the multi-core terminal needs to share the resource, the status bit reading module 201 reads the status bit of the shared mutex register, so that the resource sharing module 202 sets the corresponding parameter according to the status bit of the shared mutex register.

The resource sharing module 202 first determines whether the status bit of the shared mutex register is idle. When the status bit of the shared mutex register is not idle, it indicates that the peer has control over the shared resource, and the current core cannot use the resource; When the status bit of the shared mutex register is idle, The information stored in the shared mutex register adjusts the corresponding parameters to achieve resource sharing. When setting parameters, you need to set the status bit of the shared mutex register to non-idle state. After the resources are shared, you need to return the status bit of the shared mutex register to the idle state.

Preferably, as shown in FIG. 3, the resource sharing module 202 includes: a setting unit 2021, a reading unit 2022, a setting unit 2023, and an updating unit 2024, where:

If the multi-core terminal is configured to include the first core and the second core, when the first core needs to perform frequency modulation and voltage regulation, the setting unit 2021 is configured to set the state position of the shared mutual exclusion register to a non-idle state. ;

The reading unit 2022 is configured to read the current frequency of the first core from the shared mutex register and compare it with the pre-adjusted core frequency;

The setting unit 2023 is configured to set a current core voltage and a current frequency of the first core according to the comparison result;

The updating unit 2024 is configured to separately write the current core voltage, the current frequency of the first core, and the minimum core voltage allowed by the first core into corresponding bits in the shared mutex register.

Preferably, the setting unit 2023 is further configured to: when the pre-adjusted core frequency is greater than a current frequency of the first core, read a current core voltage from the shared mutex register, and compare with a pre-adjusted core voltage. Reading the core voltage allowed by the second core from the shared mutual exclusion register when the pre-adjusted core voltage is greater than the current core voltage; taking the pre-adjusted core voltage and the nuclear voltage allowed by the second core The larger one is set to the current core voltage; the current frequency of the first core is set; when the pre-adjusted kernel frequency is less than the current frequency of the first core, the current frequency of the first core is set; The shared mutual exclusion register reads the current core voltage and compares with the preset core voltage; when the preset core voltage is greater than the current core voltage, reading the second core permission from the shared mutual exclusion register The core voltage; the larger of the pre-adjusted core voltage and the core voltage allowed by the second core is set to the current core voltage.

When the first core needs to adjust the system bus frequency, the reading unit 2022 is further configured to read the current bus frequency of the system and the lowest system allowed by the second core from the shared mutual exclusion register. Bus frequency

The setting unit 2023 is further configured to compare the preset core frequency, the current bus frequency of the system, and the lowest system bus frequency allowed by the second core; wherein the largest one is set to the current bus frequency of the system; the update unit 2024 is further configured to The current bus frequency of the system and the lowest system bus frequency allowed by the second core are respectively written into corresponding bits in the shared mutex register.

When the multi-core terminal shares the RF common resource, the reading unit 2022 is further configured to read from the shared mutual exclusion register when any of the multi-core terminals wants to enter a sleep state or when awake The RF common resource state; the setting unit 2023 is further configured to: when any one of the multi-core terminals wants to enter a sleep state and the corresponding RF common resource state is an active state, the corresponding RF common resource The state is set to a power-saving state; or, when any one of the multi-core terminals is awake and the corresponding RF common resource state is a power-saving state, the corresponding RF common resource state is restored to a working state. ;

The update unit 2024 is further configured to write the current state of the RF common resource into the corresponding bit of the mutually exclusive shared register.

The setting unit 2021 is further configured to return the status bit of the shared mutex register to an idle state after the resource sharing is completed.

The method and device for sharing resources by a multi-core terminal according to an embodiment of the present invention, for a multi-core terminal, when there are multiple shared resources, the shared mutual exclusion register is used to protect and coordinate the use of the shared resource, and one of the cores in the multi-core terminal needs to be used. When the resource is shared, the status bit of the shared mutex register is read; when the status bit of the shared mutex register is idle, the corresponding parameter is set according to the information stored in the shared mutex register for resource sharing, thereby coordinating the check resources of the shared resources. Distribution increases the utilization of public resources and improves the overall performance of the terminal system.

One of ordinary skill in the art can understand that all or part of the above steps can be completed by a program to instruct related hardware, and the above program can be stored in a computer readable storage medium, such as read only. Memory, disk or disc, etc. Alternatively, all or part of the steps of the above embodiments may also be implemented using one or more integrated circuits. Correspondingly, each module/unit in the foregoing embodiment may be implemented in the form of hardware, or may be implemented in the form of a software function module. The invention is not limited to any specific form of combination of hardware and software.

The above is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention, and equivalent structural or process changes made by the present specification and drawings may be directly or indirectly applied to other related technical fields. The same is included in the scope of patent protection of the present invention.

Industrial applicability

Embodiments of the present invention coordinate the allocation of shared resources by each core, improve the utilization rate of public resources, and improve the overall performance of the terminal system.

Claims

1. A method for sharing resources by a multi-core terminal, comprising:

2. The method of claim 1, wherein the shared resource comprises at least one of the following: a multi-core frequency modulation, a radio frequency (RF) common resource, an I2C bus, and a universal asynchronous transceiver transmitter (UART) serial port.

The method according to claim 1, wherein the multi-core terminal comprises a first core and a second core, and when the first core needs to perform frequency modulation and voltage regulation, the information is set according to the information stored in the shared mutual exclusion register. The steps to share resource parameters include:

Setting a status bit of the shared mutex register to a non-idle state;

4. The method according to claim 3, wherein the step of setting the current nuclear voltage and the current frequency of the first core according to the comparison result comprises:

The method according to claim 1, wherein the multi-core terminal comprises a first core and a second core, and when the first core needs to adjust a system bus frequency, the information is set according to the information stored in the shared mutex register. The steps to share resource parameters include:

Setting a status bit of the shared mutex register to a non-idle state;

The current bus frequency of the system and the lowest system bus frequency allowed by the second core are respectively written into the shared mutex register.

66. The root method according to the claim of claim 11 according to the rights and interests, wherein, the multi-core nuclear terminal terminal shared the RRFF public common resource source At the time, the step by step according to the shared information sharing the shared information of the mutual-reserved register storage storage device sets the number of shared resource resource parameter parameters :: When any of the multi-nuclear nuclear terminal terminals in the described multi-nuclear nuclear terminal end point is intended to enter the sleep-sleeping state state, the mutual sharing of the mutual sharing is In the register, the reading and reading of the RRFF public common resource source state state; if the RRFF public common resource source state state is the working state state, then The 2200 RRFF public common resource source state state state is set to be a provincial power state state, and the current front state of the RRFF public common resource source will be State-state write write-in to the mutual repudiation co-shared register register ;;

When any one of the multi-core core terminal terminals of the said multi-core core terminal is awake at the time of wake-up, reading from the shared shared mutual exclusion register Reading the RRFF public common resource source state state; if the RRFF public common resource source state state is the provincial power state state, then the description will be The source state state of the public public resources of the RRFF is restored to the working state state, and the current state of the current public resource source of the RRFF is written and written into the office. The mutually exclusive replies are shared and shared in the 2255 stor. .

77. The method according to any one of the items 33-66, according to the rights and interests of the right, and the package includes:

After the sharing of the resource resources is completed, the state status bits of the shared mutual shared register are returned to the empty idle state. . .

9. The apparatus of claim 8, wherein the shared resource comprises at least one of the following: a multi-core frequency modulation, a radio frequency (RF) common resource, an I2C bus, and a universal asynchronous transceiver transmitter (UART) serial port. The device according to claim 8, wherein the multi-core terminal comprises a first core and a second core, and when the first core needs to perform frequency modulation and voltage regulation, the resource sharing module includes:

And an update unit configured to write the current core voltage, a current frequency of the first core, and a minimum core voltage allowed by the first core into the shared mutex register, respectively. The device according to claim 10, wherein the setting unit is further configured to: read the current core from the shared mutex register when the pre-adjusted core frequency is greater than a current frequency of the first core The voltage is compared with the pre-adjusted core voltage; when the pre-adjusted core voltage is greater than the current core voltage, the core voltage allowed by the second core is read from the shared mutex register; And a larger one of a voltage and a core voltage allowed by the second core is set as a current core voltage; setting a current frequency of the first core; when the pre-adjusted core frequency is less than a current frequency of the first core, setting Determining a current frequency of the first core; reading a current core voltage from the shared mutex register, comparing with a pre-adjusted core voltage; and when the pre-adjusted core voltage is greater than the current core voltage, mutually exclusive from the sharing The register reads the core voltage allowed by the second core; and takes the larger of the pre-adjusted core voltage and the core voltage allowed by the second core as the current core voltage. The device according to claim 8, wherein the multi-core terminal comprises a first core and a second core, and when the first core needs to adjust a system bus frequency, the resource sharing module comprises: a setting unit, It is set to set a status bit of the shared mutex register to a non-idle state; a reading unit configured to: read a current bus frequency of the system from the shared mutex register, and a minimum allowed by the second core System bus frequency;

The apparatus according to claim 8, wherein the multi-core terminal comprises a first core and a second core, and when the multi-core terminal shares an RF common resource, the resource sharing module comprises: a reading unit, which is set When: any one of the multi-core terminals wants to enter a sleep state or wakes up, reads an RF common resource state from the shared mutual exclusion register;

The updating unit is configured to: write a current state of the RF common resource into the mutually exclusive shared register.

The device according to any one of claims 10-13, wherein the setting unit is further configured to: after the resource sharing is completed, return the status bit of the shared mutex register to an idle state.