Method and apparatus for determining time parameter

By configuring multiple sets of time parameters in the chip and determining the adapted time parameters according to the configuration request type, the problem that Hibernate Mode cannot adapt to different scenarios in the UFS protocol is solved, improving user experience and efficiency.

WO2025167230A1PCT designated stage Publication Date: 2025-08-14HUAWEI TECH CO LTD
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2024/129361
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-02-08
Filing Date
2024-11-01
Publication Date
2025-08-14

AI Technical Summary

Technical Problem

In the UFS protocol, the time parameter configuration of Hibernate Mode cannot be adapted to different scenarios, resulting in the H8 advancing and retreating time exceeding the time limit, affecting the user experience.

Method used

By configuring multiple sets of time parameters in the chip, the adaptation time parameters are determined according to the type of configuration request, scene adaptation is realized, and the time characteristics and user experience of different sleep scenarios are met.

Benefits of technology

It improves the efficiency of advancement and retreat of Hibernate Mode, improves user experience, and enhances product competitiveness.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN2024129361_14082025_PF_FP_ABST
    Figure CN2024129361_14082025_PF_FP_ABST
Patent Text Reader

Abstract

The present application relates to the field of chips. Provided are a method and apparatus for determining a time parameter, which method and apparatus aim to determine a scenario-adaptive time parameter, so as to ensure user experience. The method comprises: determining the type of a configuration request; and executing an operation of the configuration request on the basis of a time parameter corresponding to the type of the configuration request, wherein the time parameter corresponding to the type of the configuration request is one of a plurality of time parameters.
Need to check novelty before this filing date? Find Prior Art

Description

Method and device for determining time parameters

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on February 8, 2024, with application number 202410179369.7 and application name “A method and device for determining time parameters”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of chips, and in particular to a method and device for determining time parameters. Background Art

[0003] In the mobile terminal market, due to their high sensitivity to power consumption, various low-power chip technologies and methods are needed to improve terminal battery life. Universal flash storage (UFS), as a storage component in current mobile terminals, has a comprehensive low-power system defined in the UFS standard protocol to reduce the power consumption of storage devices.

[0004] UniPro Hibernate_Mode (sleep mode) is a low-power mode commonly used by UFS. It is the lowest power consumption mode except for off Mode. UniPro Hibernate_Mode can also be called Hibernate8 (H8).

[0005] In the UFS protocol, Hibernate entry is initiated by the UFS host. Hibernate modes are categorized as Suspend H8 and Auto H8. Suspend H8 requires the host software to proactively issue an SSU command to the HCI layer before issuing a Hibernate request to the UniPro layer. Auto H8, on the other hand, occurs when the host logic automatically issues a UniPro Hibernate request after a prolonged period of no UFS HCI commands.

[0006] After receiving a UniPro Hibernate request, the device must complete the table entry power preservation and hardware power-off process within the time period indicated by the parameter T_hibern8. After receiving a Hibernate exit request, the device must complete the table entry restoration and hardware power-on process within the time period indicated by the parameter T_active. The T_hibern8 and T_active time parameters are important indicators of Hibernate exit performance, and all manufacturers prefer to keep them as low as possible. However, in practice, Hibernate exit time parameters are configured only for the worst-case scenario, resulting in excessive Hibernate exit times and a negative user experience.

[0007] Summary of the Invention

[0008] The embodiments of the present application provide a method and apparatus for determining time parameters, which can determine the time parameters for an adaptation scenario to ensure user experience.

[0009] To achieve the above objectives, the present invention adopts the following technical solutions:

[0010] In a first aspect, a method for determining a time parameter is provided, which is applied to a first chip in a communication system. The first chip is configured with multiple sets of time parameters, and at least one time parameter in different sets of time parameters has a different value. The method may include: determining a type of configuration request; and performing an operation of the configuration request according to the time parameter corresponding to the type of configuration request. The time parameter corresponding to the type of configuration request is one of the multiple sets of time parameters.

[0011] Through the solution provided in this application, since the type of configuration request reflects a specific scenario, as long as the time parameters corresponding to the type of configuration request are adapted to the scenario, the operation of the configuration request is performed according to the time parameters corresponding to the type, thereby achieving the purpose of determining the time parameter adaptation scenario, and thus achieving both the time characteristics of the scenario and the user experience under the scenario.

[0012] In one possible implementation, the configuration request may be a UFS sleep request, so that the determined time parameters can be adapted to different sleep scenarios in the UFS, thereby satisfying both the time characteristics of different sleep scenarios and the user experience in different sleep scenarios.

[0013] In another possible implementation, the first chip is a UFS host. Determining the type of configuration request can be specifically implemented by receiving a first indication from the host's software layer and determining that the type of the sleep request is a suspend sleep request, Suspend H8. The first indication is used to instruct the sending of a sleep request. Since Suspend H8 is initiated by the host software layer, upon receiving the indication from the host software layer, it can be determined that the type of sleep request is Suspend H8. This method determines the type of sleep request based on the source of the indication information, maintaining compatibility with existing protocols.

[0014] In another possible implementation, the first chip is a UFS host Host, and determining the type of the configuration request can be specifically implemented as follows: receiving a second indication from the host controller interface (HCI) of the Host, and determining that the type of the sleep request is an automatic sleep request Auto H8; the second indication is used to indicate sending a sleep request. Since Auto H8 is initiated by the HCI layer of the Host, when an indication is received from the HCI layer of the Host, it can be determined that the type of the sleep request is Auto H8. This method realizes the determination of the type of sleep request based on the source of the indication information, and is compatible with existing protocols.

[0015] In another possible implementation, the first chip is a UFS host. Determining the type of configuration request can be specifically implemented as follows: receiving a third indication from the Host's HCI; the third indication is used to indicate that the type of the sleep request is Auto H8 or Suspend H8; and determining that the type of the sleep request is the type indicated by the third indication. In this implementation, after the HCI determines the type of the current sleep request, it sends a third indication to indicate the type of the current sleep request, allowing the Host's hardware logic to determine the type of the sleep request. This achieves the determination of the type of sleep request based on the source of the indication information, and is compatible with existing protocols.

[0016] In another possible implementation, the method provided in this application may further include: sending a sleep request carrying a fourth indication to the UFS device, where the fourth indication is used to indicate the type of the sleep request. In this implementation, the host sends an indication to the device to indicate the type of the sleep request, making it easier for the device to easily identify the type of sleep request and then determine time parameters that are suitable for the scenario, thereby improving the user experience.

[0017] In another possible implementation, the first chip is a UFS device. Determining the type of the configuration request can be specifically implemented by: receiving a sleep request from a UFS host, the sleep request including a fourth indication indicating a type; and determining the type of the sleep request to be the type indicated by the fourth indication. In this implementation, the host sends an indication to the device indicating the type of the sleep request, making it easier for the device to identify the type of sleep request and determine time parameters appropriate for the scenario, thereby improving the user experience.

[0018] In another possible implementation, the first chip is UFSDevice, and the above-mentioned determination of the type of configuration request can be specifically implemented as follows: UFSDevice receives a sleep request from the UFS Host. If the UFS Transport Layer (UTP) layer of the Device receives an SSU (START STOP UNIT) command, it determines that the type of sleep request is Suspend H8; if the UTP layer of the Device does not receive an SSU command, it determines that the type of sleep request is Auto H8. In this implementation, after receiving a sleep request from the UFS Host, the UFSDevice identifies the type of sleep request based on whether the UTP layer receives an SSU command. On the basis of compatibility with existing protocols, the logic influences the identification of the type of sleep request, and then determines the time parameters for the adaptation scenario to improve the user experience.

[0019] In another possible implementation, the sleep request may be a request to enter a sleep state, or a request to exit a sleep state.

[0020] In another possible implementation, the method provided in the present application may further include: after the link is established, obtaining multiple sets of time parameters configured in the second chip; and calculating multiple sets of time parameters of the first chip based on the multiple sets of time parameters configured in the second chip.

[0021] In another possible implementation, the method provided in the present application may further include: after the link establishment is completed, configuring multiple groups of time parameters for the second chip.

[0022] In another possible implementation, the method provided in the present application may further include: sending a data frame to the second chip, where the data frame includes multiple groups of time parameters.

[0023] In another possible implementation, the data frame is PACP_CAP_EXT2_ind, or PACP_CAP_EXT1_ind, or PACP_CAP_ind in the UniPro protocol.

[0024] In another possible implementation, the first time parameter corresponding to Suspend H8 is greater than the first time parameter corresponding to Auto H8; the first time parameter is any time parameter in a group of time parameters.

[0025] In another possible implementation, the set of time parameters includes one or more of T_hibern8, T_active, SaveConfigTime, StallNoConfigTime, SleepNoConfigTime, or TxTrailingClocks in the UniPro protocol.

[0026] Among them, T_hibern8 is used to indicate the duration of entering the hibernation state, and T_active is used to indicate the duration of exiting the hibernation state. SaveConfigTime is used to indicate the time interval (i.e., waiting time) in the STALL / SLEEP state (no data transmission state) after the speed is switched before data at the new rate can be initiated. StallNoConfigTime is used to indicate the interval between data bursts in the high-speed FAST AUTO mode; SleepNoConfigTime is used to indicate the interval between data bursts in the low-speed SLOW AUTO mode. TxTrailingClocks is used to indicate how long it takes to turn off the clock (Tx Symbol Clcok) after the burst ends.

[0027] In a second aspect, a device for determining a time parameter is provided, which is applied to a first chip in a communication system, wherein the first chip is configured with multiple sets of time parameters, and at least one time parameter in different sets of time parameters has a different value. The device may include: a determination unit and a processing unit.

[0028] The first acquiring unit is configured to determine a type of the configuration request.

[0029] The second acquiring unit is configured to execute the operation of the configuration request according to the time parameter corresponding to the type of the configuration request, where the time parameter corresponding to the type is one of the multiple groups of time parameters.

[0030] In one possible implementation, the configuration request may be a UFS sleep request, so that the determined time parameters can be adapted to different sleep scenarios in the UFS, thereby satisfying both the time characteristics of different sleep scenarios and the user experience in different sleep scenarios.

[0031] In another possible implementation, the first chip is a UFS host, and the determination unit is specifically configured to receive a first indication from the host's software layer and determine that the type of the sleep request is a suspend sleep request, Suspend H8. The first indication is used to instruct the sending of a sleep request. Because Suspend H8 is initiated by the host software layer, upon receiving the indication from the host software layer, the type of the sleep request can be determined to be Suspend H8. This achieves the determination of the sleep request type based on the source of the indication information, and is compatible with existing protocols.

[0032] In another possible implementation, the first chip is a UFS host, and the determination unit is specifically configured to: receive a second indication from the Host's HCI to determine that the type of the sleep request is an automatic sleep request Auto H8; the second indication is used to indicate sending a sleep request. Since Auto H8 is initiated by the Host's HCI layer, upon receiving an indication from the Host's HCI layer, it is possible to determine that the type of sleep request is Auto H8. This allows the type of sleep request to be determined based on the source of the indication information, maintaining compatibility with existing protocols.

[0033] In another possible implementation, the first chip is a UFS host, and the determination unit is specifically configured to: receive a third indication from the Host's HCI; the third indication is used to indicate that the type of the sleep request is Auto H8 or Suspend H8; and determine that the type of the sleep request is the type indicated by the third indication. In this implementation, after the HCI determines the type of the current sleep request, it sends the third indication to indicate the type of the current sleep request, allowing the Host's hardware logic to determine the type of the sleep request. This achieves the ability to determine the type of the sleep request based on the source of the indication information, and is compatible with existing protocols.

[0034] In another possible implementation, the apparatus further includes a sending unit configured to send a sleep request carrying a fourth indication to the UFS device, where the fourth indication indicates the type of the sleep request. In this implementation, the host sends an indication to the device indicating the type of the sleep request, making it easier for the device to identify the type of sleep request and determine time parameters suitable for the scenario, thereby improving the user experience.

[0035] In another possible implementation, the first chip is a UFS device, and the determination unit is specifically configured to: receive a sleep request from a UFS host, the sleep request including a fourth indication indicating a type; and determine the type of the sleep request to be the type indicated by the fourth indication. In this implementation, the host sends an indication to the device indicating the type of the sleep request, making it easier for the device to identify the type of the sleep request and determine time parameters appropriate for the scenario, thereby improving the user experience.

[0036] In another possible implementation, the first chip is a UFS device, and the determination unit is specifically used to: UFSDevice receives a sleep request from the UFS Host. If the UFS Transport Layer (UTP) layer of the Device receives an SSU (START STOP UNIT) command, it determines that the type of the sleep request is Suspend H8; if the UTP layer of the Device does not receive an SSU command, it determines that the type of the sleep request is Auto H8. In this implementation, after receiving the sleep request from the UFS Host, the UFSDevice identifies the type of sleep request based on whether the UTP layer receives an SSU command. On the basis of compatibility with existing protocols, the logic influences the identification of the type of sleep request, and then determines the time parameters for the adaptation scenario to improve the user experience.

[0037] In another possible implementation, the sleep request may be a request to enter a sleep state, or a request to exit a sleep state.

[0038] In another possible implementation, the device further includes an acquisition unit configured to: after link establishment is completed, acquire multiple sets of time parameters configured in the second chip; and calculate multiple sets of time parameters of the first chip based on the multiple sets of time parameters configured in the second chip.

[0039] In another possible implementation, the apparatus further includes a configuration unit configured to: after the link is established, configure multiple groups of time parameters for the second chip.

[0040] In another possible implementation, the device further includes a sending unit, configured to send a data frame to the second chip, where the data frame includes the multiple groups of time parameters.

[0041] In another possible implementation, the data frame is PACP_CAP_EXT2_ind, or PACP_CAP_EXT1_ind, or PACP_CAP_ind.

[0042] In another possible implementation, the first time parameter corresponding to Suspend H8 is greater than the first time parameter corresponding to Auto H8; the first time parameter is any time parameter in a group of time parameters.

[0043] In another possible implementation, the set of time parameters includes one or more of T_hibern8, T_active, SaveConfigTime, StallNoConfigTime, SleepNoConfigTime, or TxTrailingClocks in the UniPro protocol.

[0044] In a third aspect, a chip is provided, which includes a memory and at least one processor, the memory being used to store a set of computer instructions; when the processor executes the computer instructions, the chip executes the operating steps of the method described in the first aspect or any possible implementation method.

[0045] In a fourth aspect, a mobile terminal is provided, comprising the chip as described in the third aspect.

[0046] In a fifth aspect, a computer-readable storage medium is provided, comprising: computer software instructions; when the computer software instructions are executed in a computer, the computer executes the operating steps of the method described in the first aspect or any possible implementation method.

[0047] In a sixth aspect, a computer program product is provided, which, when executed on a computer, enables the computer to execute the operating steps of the method described in the first aspect or any possible implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] FIG1 is a schematic diagram of a protocol stack structure of a UFS protocol;

[0049] FIG2 is a schematic structural diagram of a mobile phone provided in an embodiment of the present application;

[0050] FIG3 is a flow chart of a method for determining a time parameter provided in an embodiment of the present application;

[0051] FIG4 is a schematic structural diagram of a device for determining a time parameter provided in an embodiment of the present application;

[0052] FIG5 is a schematic structural diagram of another device for determining time parameters provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] For ease of understanding, some examples of concepts related to the embodiments of this application are provided for reference as follows:

[0054] UFS generally refers to two things: 1) a storage interface protocol for mobile devices; 2) storage devices that use this protocol. Storage devices that use the UFS protocol are built using serial data transmission technology, allowing them to be erased or written multiple times during operation.

[0055] UniPro: A layered protocol that defines the interconnection between devices and components within consumer electronics products such as mobile devices. It applies to devices such as application processors, coprocessors, and modems, as well as data transmission, including control signals, bulk data transfers, and packet streams. UniPro serves as the data link layer of the UFS, responsible for connecting the host and device.

[0056] HCI (Host Controller Interface) provides a unified hardware interface for UFS, facilitating the use of a unified driver for the host controller. UFS is applied to different platform devices, and different platform devices communicate with UFS through HCI.

[0057] The SSU command is used to switch power modes during UFS power management. It is a basic command in the UFS protocol. The SSU command is used to enable or disable a LU, flush the cache to the device, or load or eject the device. The host switches the power mode of the device by sending the SSU command to the well-known logical unit of the UFS device.

[0058] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0059] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this embodiment, unless otherwise specified, "plurality" means two or more.

[0060] Among them, the UFS protocol specifically includes the application layer (UFS Application Layer, UAP), the transport layer (UTP) and the link layer (UFS InterConnect Layer, UIC). Among them, the application layer can issue a small computer system interface (SCSI) command, and the SCSI is packaged into a UFS protocol information unit (UPIU) at the transport layer, and then the data is sent to the other end through the link layer. Among them, the link layer includes the data link layer (UniPro) and the physical layer (M-PHY). The data link layer is responsible for the connection between the Host and the Device. M-PHY is responsible for transmitting data, for example, using differential signals for data transmission. Exemplarily, the protocol stack structure of the UFS protocol can be shown in Figure 1.

[0061] The data link layer includes a transmitting circuit and a receiving circuit, and the physical layer also includes a transmitting circuit and a receiving circuit. For the host or device, the transmitting circuit in the interconnection interface may include the transmitting circuit of the data link layer and the transmitting circuit of the physical layer, and the receiving circuit in the interconnection interface may include the receiving circuit of the data link layer and the receiving circuit of the physical layer.

[0062] The data link layer protocol itself is a complete protocol stack. As shown in Figure 1, the UniPro protocol specification consists of four main layers: the physical adapter layer (L1.5), the data link layer (L2), the network layer (L3), the transport layer (L4), and a device management entity (DME). Below the physical adapter layer are the physical layer and the transmission medium transport layer, and above that are the application-specific protocols.

[0063] The following describes the different types of UniPro Hibernate Mode in the UFS standard protocol. Hibernate Mode is divided into Suspend H8 and Auto H8.

[0064] Suspend H8 requires the host software to proactively issue an SSU command at the HCI layer before issuing a Hibernate request at the UniPro layer. When Suspend H8 is enabled, the host typically powers down the entire host controller.

[0065] Auto H8: When the HCI has no commands for a long time, the host side logic automatically sends a UniPro Hibernate request. In Auto-H8, the host side generally does not perform power-off processing.

[0066] After receiving the UniPro Hibernate request, the device performs the table entry power preservation and hardware power-off process. After receiving the H8 exit request, the device restores the table entry and hardware power-on process.

[0067] Regarding the specific scenarios in which Hibernate_Mode occurs, the embodiments of this application do not limit the specific mechanisms for triggering different types of Hibernate_Mode. For example, in the IDLE scenario, Supsend H8 is mainly issued, and the terminal may perform this IDLE scenario when the screen is off. In the user scenario (i.e., when the user is using the mobile terminal), Auto H8 is mainly issued.

[0068] The following compares the parameters of various dimensions of Suspend H8 and Auto H8 from the perspectives of the host and device.

[0069] Table 1 compares the parameters of various dimensions between Suspend H8 and Auto H8 on the host side. Table 2 compares the parameters of various dimensions between Suspend H8 and Auto H8 on the device side.

[0070] Table 1

[0071] Table 2

[0072] Typically, time parameters are defined in USF to indicate time-related processes of the USF system.

[0073] For example, the time parameter may include one or more of T_hibern8, T_active, SaveConfigTime, StallNoConfigTime, SleepNoConfigTime, or TxTrailingClocks in the UniPro protocol.

[0074] Among them, T_hibern8 is used to indicate the duration of entering the hibernation state, and T_active is used to indicate the duration of exiting the hibernation state. SaveConfigTime is used to indicate the time interval (i.e., waiting time) in the STALL / SLEEP state (no data transmission state) after the speed is switched before data at the new rate can be initiated. StallNoConfigTime is used to indicate the interval between data bursts in the high-speed FAST AUTO mode; SleepNoConfigTime is used to indicate the interval between data bursts in the low-speed SLOW AUTO mode. TxTrailingClocks is used to indicate how long it takes to turn off the clock (Tx Symbol Clcok) after the burst ends.

[0075] The following description is given by taking the time parameters T_hibern8 and T_active as an example.

[0076] After receiving the UniProHibernate request, the device performs the table entry power preservation and hardware power-down process, which must be completed within the time period indicated by T_hibern8. After receiving the request to exit H8, the table entry and hardware power-up process must be restored, which must be completed within the time period indicated by T_active.

[0077] The host also requires corresponding time parameters (T_hibern8 and T_active) to confirm that the host and device have completed the process of entering or exiting H8, and that the host has completed the power-off or power-on process. The host's time parameters can be determined based on the device's time parameters and the host's capabilities.

[0078] The existing UniPro protocol specifies that during the link establishment phase, the host or device obtains the T_active and T_hibern8 parameters of the peer's Rx (receive) direction and then calculates the corresponding Tx (transmit) time parameter values ​​based on the local capabilities and configures them locally. The specific calculation process can be found in the UniPro protocol and is not detailed in this application.

[0079] From the current MPHY protocol (see Table 3 below), these two parameters have fine-grained mode (unit: 4 / 8 / 16 / 32 microseconds) and coarse-grained mode (100 microseconds), where T_hibern8 ranges from 1 to 128 and T_active ranges from 1 to 14.

[0080] Table 3

[0081] As can be seen from the preceding, the time parameter is a key indicator of H8 performance, and all equipment manufacturers prefer to keep it as low as possible. These two performance parameters must be determined based on the worst-case scenario. For example, Supsend H8 takes longer to organize than Auto H8, and the worst-case parameters are determined by the parameters used in Suspend H8. This results in using poor parameters in Auto H8 scenarios, directly affecting H8 startup and shutdown times, and ultimately impacting the user experience.

[0082] In this regard, this application proposes a method for determining time parameters. By configuring different time parameters corresponding to different request types, the time parameters adapted to the request are determined. On the premise of adapting to different scenarios, the shortest time parameters adapted to the scenario are determined to improve the user experience.

[0083] The solution provided in this application can be applied to mobile terminals, and the mobile device can be a mobile phone, a tablet computer, a laptop computer, an ultra-mobile personal computer (UMPC), a handheld computer, a netbook, a personal digital assistant (PDA), a wearable electronic device, a virtual reality device, etc., and the embodiments of this application do not impose any restrictions on this.

[0084] For example, as shown in FIG2 , the mobile device in the embodiment of the present application may be a mobile phone 100. The embodiment will be described in detail below using the mobile phone 100 as an example. It should be understood that the illustrated mobile phone 100 is merely an example of the electronic device described above, and that the mobile phone 100 may have more or fewer components than shown in the figure, may combine two or more components, or may have a different component configuration.

[0085] As shown in FIG2 , the mobile phone 100 includes a main chip 101, an internal memory 121, an external memory interface 122, an antenna A, a mobile communication module 131, an antenna B, a wireless communication module 132, an audio module 140, a speaker 140A, a receiver 140B, a microphone 140C, an earphone interface 140D, a display 151, a subscriber identification module (SIM) card interface 152, a camera 153, a button 154, a sensor module 160, a universal serial bus (USB) interface 170, a charging management module 180, a power management module 181, and a battery 182. In other embodiments, the mobile phone 100 may further include a motor, an indicator, and the like.

[0086] The main chip 101 may include one or more processing units. For example, the main chip 101 may include an application processor (AP), a modem, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). It should be noted that different processing units may be independent devices or integrated into one or more independent processors, and may be integrated into the same device with other modules in the mobile phone 100.

[0087] The internal memory 121 can be used to store data and / or at least one computer program, which includes instructions. Specifically, the internal memory 121 may include a program storage area and a data storage area. The program storage area may store at least one computer program. Computer programs may include applications (such as a gallery, contacts, etc.), operating systems (such as an Android operating system, or an IOS operating system, etc.), or other programs. The data storage area may store at least one of the data created during the use of the mobile phone 100, data received from other devices (such as other mobile phones 100, network devices, servers, etc.), or data pre-stored before leaving the factory. For example, the data stored in the internal memory 121 may be at least one of images, files, or identification information.

[0088] In some embodiments, the internal memory 121 may include high-speed random access memory and / or non-volatile memory. For example, the internal memory 121 may include one or more disk storage devices, flash memory, or universal flash storage (UFS).

[0089] The main chip 101 can call one or more computer programs and / or data stored in the internal memory 121 to enable the mobile phone 100 to implement one or more functions to meet the user's needs. For example, the main chip 101 can call instructions and data stored in the internal memory 121 to enable the electronic device to execute the message notification method provided in the embodiment of the present application.

[0090] The external memory interface 122 can be used to connect an external memory card (e.g., a Micro SD card) to expand the storage capacity of the mobile phone 100. The external memory card communicates with the main chip 101 through the external memory interface 122 to implement data storage functions. For example, files such as images, music, and videos can be stored in the external memory card.

[0091] In some embodiments, a cache area may be provided in the master chip 101 to store instructions and / or data that the master chip 101 needs to reuse. If the master chip 101 needs to use the instruction or data again, it can directly call it from the cache area. This helps avoid repeated accesses, reduces the waiting time of the master chip 101, and thus helps improve system efficiency. For example, the cache area can be implemented as a high-speed cache memory.

[0092] It should be understood that the structure of the mobile phone 100 shown in FIG2 is merely an example. The mobile phone 100 of the embodiment of the present application may have more or fewer components than shown in the figure, may combine two or more components, or may have a different component configuration. The various components shown in the figure may be implemented in hardware, including one or more signal processing and / or application-specific integrated circuits, software, or a combination of hardware and software.

[0093] The main chip 101 may be a Host in the UFS protocol, and the internal memory 121 may be a Device in the UFS protocol.

[0094] The following is an introduction to the embodiments of the present application.

[0095] On the one hand, an embodiment of the present application provides a method for determining a time parameter, which can be applied to a first chip in a communication system. Multiple groups of time parameters are configured in the first chip, and at least one time parameter in different groups of time parameters has a different value.

[0096] Exemplarily, the first chip may be a Host or a Device in the UFS protocol. The set of time parameters includes one or more of T_hibern8, T_active, SaveConfigTime, StallNoConfigTime, SleepNoConfigTime, or TxTrailingClocks in the UniPro protocol.

[0097] For example, one set of time parameters can be lower power consumption, corresponding to a higher performance Suspend H8 with a longer time parameter; another set of time parameters can be higher performance, corresponding to Auto H8 with a shorter time parameter. This allows different UFS H8 low power parameters (time parameters) to be selected according to different scenarios, ensuring reduced power consumption while improving the user experience and enhancing product competitiveness.

[0098] Exemplarily, the first time parameter corresponding to Suspend H8 is greater than the first time parameter corresponding to Auto H8; the first time parameter is any time parameter in a group of time parameters.

[0099] Of course, the solution provided in the embodiments of the present application can also be applied to other communication systems besides UFS. Any system that requires different time parameters in different scenarios can use the solution provided in this application to determine the time parameters that match the scenario.

[0100] As shown in FIG3 , the method for determining time parameters provided in an embodiment of the present application may include:

[0101] S301: The first chip determines the type of configuration request.

[0102] Among them, the configuration request can be a request transmitted between the first chip and other chips in the communication system for implementing the configuration function. The embodiment of the present application does not limit the specific type of the configuration request.

[0103] For example, the configuration request may be a hibernation request (H8 request) in UFS. Of course, the configuration request may also be other requests in UFS, and the embodiment of the present application does not limit the type of the configuration request.

[0104] The following takes the configuration request being a UFS hibernation request as an example to describe in detail the type of the configuration request determined in S301, which may include but is not limited to the following possible implementations:

[0105] Implementation 1: The first chip is a UFS host Host, and determines the type of the configuration request. The specific implementation is: receiving a first indication from the software layer of the Host, and determining that the type of the hibernation request is Suspend H8.

[0106] In implementation 1, the UniPro layer of the first chip may receive the first indication from the software layer of the Host.

[0107] The first instruction is used to instruct sending a sleep request. The specific form and content of the first instruction are not limited in this embodiment of the application.

[0108] Exemplarily, the first indication may be a primitive or a command.

[0109] Implementation 2: The first chip is the UFS host Host, and determines the type of the configuration request. The specific implementation is: receiving the second indication from the HCI of the Host, and determining that the type of the sleep request is Auto H8.

[0110] In implementation 2, the UniPro layer of the first chip may receive the second indication from the HCI of the host.

[0111] The second instruction is used to instruct sending a sleep request. The specific form and content of the second instruction are not limited in this embodiment of the application.

[0112] Exemplarily, the second instruction may be a primitive or a command.

[0113] Implementation 3: The first chip is a UFS host, and determines the type of the configuration request. The specific implementation is: receiving a third indication from the HCI of the host. The third indication is used to indicate that the type of the sleep request is Auto H8 or Suspend H8; and determining that the type of the sleep request is the type indicated by the third indication.

[0114] In implementation 3, the host's HCI can determine the type of the currently issued hibernation request based on whether the host's software layer has issued an SSU command. If the HCI observes that the software layer has issued an SSU command, it determines that the currently issued hibernation request is Suspend H8. If the HCI does not observe that the software layer has issued an SSU command, it determines that the currently issued hibernation request is Auto H8.

[0115] In any of the above implementations 1 to 3, a Hibernate type register may be added in the UniPro layer to inform the host's hardware logic of the type of the Hibernate request being sent.

[0116] Furthermore, based on any one of Implementations 1 to 3 above, the solution provided in this embodiment of the present application may further include: the first chip sending a sleep request carrying a fourth indication to the UFSDevice, where the fourth indication is used to indicate the type of the sleep request. That is, the sleep request carries the fourth indication so that the device can determine the type of the sleep request based on the fourth indication.

[0117] For example, the PACP_PWR_req frame information of the original Unipro Hibernate request can be modified, and the reserved field therein can be used to indicate the Hibernate request type (ie, as the fourth indication), so as to identify the type of the hibernate request at the L1.5 layer on the device side.

[0118] Illustratively, the format of the PACP_PWR_req frame information may be as shown in Table 4 below, where the reserved field may be the reserved field in the Flags field.

[0119] Table 4

[0120] Implementation 4: The first chip is a UFS device Device, and determines the type of the configuration request, which is specifically implemented as follows: receiving a sleep request from the UFS host Host, where the sleep request includes a fourth indication for indicating a type; and the Device determines that the type of the sleep request is the type indicated by the fourth indication.

[0121] Implementation 4 corresponds to the above implementation 3, and the specific implementation will not be repeated here.

[0122] However, since the recognition of the SSU command on the device side is implemented at the software layer, the processing delay of implementing solution 4 will be relatively large.

[0123] Implementation 5: The first chip is a UFS device, and determines the type of the configuration request. Specifically, the device receives a hibernation request from the UFS host. If the UTP layer of the device receives an SSU command, the device determines that the type of the hibernation request is Suspend H8; if the UTP layer of the device does not receive the SSU command, the device determines that the type of the hibernation request is Auto H8.

[0124] It should be noted that the above-mentioned implementations are merely examples of S301 and do not constitute a specific limitation.

[0125] Furthermore, the above-mentioned sleep request may include a request to enter a sleep state or a request to exit a sleep state, which is not limited in the embodiment of the present application.

[0126] S302: The first chip executes the configuration request operation according to the time parameter corresponding to the type.

[0127] The time parameter corresponding to the type is one of multiple groups of time parameters.

[0128] Specifically, multiple groups of configuration request types corresponding to time parameters may be pre-configured. A time parameter group corresponding to a configuration request type is a time parameter group with the shortest duration under the premise of meeting the functional requirements of the configuration request type.

[0129] In a possible implementation, the configuration request is a request for entering a hibernation state, and the corresponding time parameter group may include T_hibern8 and T_active. The first chip completes the process of entering the hibernation state within the duration indicated by T_hibern8.

[0130] In another possible implementation, the configuration request is a request to exit the hibernation state, and the corresponding time parameter group may include T_hibern8 and T_active. The first chip completes the process of exiting the hibernation state within the duration indicated by T_active.

[0131] For the process of executing configuration requests for other time parameters, the embodiments of this application will not be described one by one, and reference can be made to the Unipro protocol.

[0132] Through the solution provided in this application, since the type of configuration request reflects a specific scenario, as long as the time parameters corresponding to the type of configuration request are adapted to the scenario, the operation of the configuration request is performed according to the time parameters corresponding to the type, thereby achieving the purpose of determining the time parameter adaptation scenario, and thus achieving both the time characteristics of the scenario and the user experience under the scenario.

[0133] Furthermore, the first chip also needs to exchange capabilities with the second chip to inform the other end of its own capabilities (such as H8 capabilities).

[0134] In a possible implementation, the method provided in the embodiment of the present application may further include: performing capability exchange after the link establishment is completed.

[0135] Exemplarily, after the link is established, capability exchange is performed, which can be specifically implemented as follows: after the link is established, the first chip obtains multiple sets of time parameters configured in the second chip; and calculates multiple sets of time parameters of the first chip based on the multiple sets of time parameters configured in the second chip.

[0136] The first chip can obtain multiple groups of time parameters configured in the second chip through the Peer Get instruction.

[0137] The specific calculation process can be referred to the calculation formula for capability exchange in the Unipro protocol, which will not be described in detail in the embodiment of this application.

[0138] Exemplarily, after the link is established, capability exchange is performed, which can be specifically implemented as follows: after the link is established, the first chip configures multiple groups of time parameters to the second chip to complete the configuration of multiple groups of time parameters in the second chip.

[0139] The first chip can configure multiple groups of time parameters in the second chip through the Peer Set instruction.

[0140] In another possible implementation, the method provided in the embodiment of the present application may further include: performing capability exchange during the link establishment process.

[0141] For example, during the link establishment process, capability exchange can be specifically implemented as follows: the first chip sends a data frame to the second chip, the data frame including the multiple sets of timing parameters configured in the first chip. The second chip then calculates the multiple sets of timing parameters for its own end based on the multiple sets of timing parameters configured in the first chip. The specific calculation process is not further described here.

[0142] The data frame sent by the first chip may be a reserved field of PACP_CAP_EXT2_ind, PACP_CAP_EXT1_ind, or PACP_CAP_ind in the Unipro protocol, with other H8 parameter groups added. The reserved field of the frame may be a reserved field in Flags, or a Reserved field.

[0143] Illustratively, the format of the PACP_CAP_ind frame may be as shown in Table 5 below.

[0144] Table 5

[0145] Illustratively, the format of the PACP_CAP_EXT1_ind frame may be as shown in Table 6 below.

[0146] Table 6

[0147] Illustratively, the format of the PACP_CAP_EXT2_ind frame may be as shown in Table 7 below.

[0148] Table 7

[0149] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the working principle of the chip. It is understandable that, in order to realize the above functions, the chip and the like include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0150] In the embodiment of the present application, the device for determining time parameters deployed in the chip can be divided into functional modules according to the above method example. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0151] In the case of dividing each functional module according to each function, Figure 4 illustrates a device 40 for determining time parameters provided in an embodiment of the present application. The device 40 for determining time parameters is used to implement the function of the first chip in the above-mentioned method embodiment. As shown in Figure 4, the device 40 for determining time parameters may include: a determination unit 401 and a processing unit 402. The determination unit 401 is used to execute the process S301 in Figure 3; the processing unit 402 is used to execute the process S302 in Figure 3. Among them, all relevant contents of each step involved in the above-mentioned method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0152] In the case of adopting an integrated unit, as shown in FIG5 , an apparatus 50 for determining time parameters provided in an embodiment of the present application is used to implement the functions of the first chip in the above-mentioned embodiment. The apparatus 50 for determining time parameters includes a processing module 501 and a communication module 502. The processing module 501 is used to control and manage the actions of the apparatus 50 for determining time parameters, and the communication module 502 is used to communicate with other devices. For example, the processing module 501 is used to execute any of the processes S301 and S302 in FIG3 ; the communication module 502 is used to execute the interaction process between the devices in FIG3 . The apparatus 50 for determining time parameters may also include a storage module 503 for storing program code and data of the apparatus 50 for determining time parameters.

[0153] The processing module 501 may be a processor or a controller. For example, it may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processing module 501 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, and so on. The communication module 502 may be a communication port, or may be a transceiver, a transceiver circuit, or a communication interface. Alternatively, the communication interface may communicate with other devices through the aforementioned elements with transceiver functions. The aforementioned elements with transceiver functions may be implemented by antennas and / or radio frequency devices. The storage module 503 may be a memory.

[0154] As mentioned above, the device 40 for determining time parameters and the device 50 for determining time parameters provided in the embodiments of the present application can be used to implement the functions of the first chip in the above-mentioned embodiments of the present application. For the sake of convenience, only the parts related to the embodiments of the present application are shown. For specific technical details not disclosed, please refer to the embodiments of the present application.

[0155] As another form of this embodiment, a chip is provided, which includes a memory and at least one processor, wherein the memory is used to store a set of computer instructions; when the processor executes the computer instructions, the chip executes the method for determining time parameters in the above method embodiment.

[0156] As another form of this embodiment, a computer-readable storage medium is provided, on which instructions are stored. When the instructions are executed, the method for determining the time parameter in the above method embodiment is executed.

[0157] As another form of this embodiment, a computer program product containing instructions is provided. When the computer program product is run on a computer, the computer is caused to execute the method for determining the time parameter in the above method embodiment.

[0158] The embodiment of the present application further provides a chip system, which includes a processor for implementing the technical method of the embodiment of the present application. In one possible design, the chip system also includes a memory for storing the necessary program instructions and / or data of the embodiment of the present application. In one possible design, the chip system also includes a memory for the processor to call the application code stored in the memory. The chip system can be composed of one or more chips, and can also include chips and other discrete devices, which is not specifically limited in the embodiment of the present application. As another form of this embodiment, a mobile terminal is provided, including the above-mentioned chip or chip system.

[0159] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0160] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0161] The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0162] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0163] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0164] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A method for determining a time parameter, characterized in that: A first chip is applied to a communication system, wherein the first chip is configured with multiple groups of time parameters, and at least one time parameter in different groups of time parameters has a different value; and the method includes: Determine the type of configuration request; The operation of the configuration request is executed according to the time parameter corresponding to the type; the time parameter corresponding to the type is one of the multiple groups of time parameters.

2. The method according to claim 1, characterized in that The configuration request is a hibernation request in the Universal Flash Storage (UFS).

3. The method according to claim 2, characterized in that The first chip is a UFS host, and determining the type of the configuration request includes: receiving a first indication from the software layer of the Host, and determining that the type of the sleep request is a suspend sleep request Suspend H8; wherein the first indication is used to instruct sending the sleep request; or, A second indication is received from a host controller interface HCI of the Host, and it is determined that the type of the sleep request is an automatic sleep request Auto H8; the second indication is used to instruct sending a sleep request.

4. The method according to claim 2, characterized in that The first chip is a UFS host, and determining the type of the configuration request includes: receiving a third indication from a host controller interface HCI of the Host; the third indication is used to indicate that the type of the sleep request is an automatic sleep request Auto H8, or a suspended sleep request Suspend H8; Determine that the type of the sleep request is the type indicated by the third indication.

5. The method according to claim 3 or 4, characterized in that The method further comprises: A sleep request carrying a fourth indication is sent to the UFS device Device, where the fourth indication is used to indicate a type of the sleep request.

6. The method according to claim 2, characterized in that The first chip is a UFS device, and determining the type of the configuration request includes: receiving the sleep request from the UFS host Host, the sleep request including a fourth indication for indicating a type; determining that the type of the sleep request is the type indicated by the fourth indication; or, Receive the sleep request from the UFS host Host, and if the UTP layer of the Device receives the SSU command, determine that the type of the sleep request is a suspend sleep request Suspend H8; if the UTP layer of the Device does not receive the SSU command, determine that the type of the sleep request is an automatic sleep request Auto H8.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: After the link is established, multiple sets of time parameters configured in the second chip are obtained; Calculate the multiple groups of time parameters of the first chip according to the multiple groups of time parameters configured in the second chip.

8. The method according to any one of claims 1 to 6, characterized in that The method further comprises: After the link is established, multiple groups of time parameters are configured for the second chip.

9. The method according to any one of claims 1 to 6, characterized in that The method further comprises: Sending a data frame to the second chip, where the data frame includes the multiple groups of time parameters.

10. The method according to claim 9, characterized in that The data frame is PACP_CAP_EXT2_ind, or PACP_CAP_EXT1_ind, or PACP_CAP_ind.

11. The method according to any one of claims 3 to 6, characterized in that: The first time parameter corresponding to the Suspend H8 is greater than the first time parameter corresponding to the Auto H8; the first time parameter is any time parameter in a group of time parameters.

12. The method according to any one of claims 1 to 11, characterized in that A set of time parameters includes one or more of T_hibern8, T_active, SaveConfigTime, StallNoConfigTime, SleepNoConfigTime, or TxTrailingClocks in the UniPro protocol.

13. A device for determining a time parameter, characterized in that: A first chip is applied to a communication system, wherein the first chip is configured with multiple groups of time parameters, and at least one time parameter in different groups of time parameters has a different value; the device includes: a determining unit, configured to determine a type of a configuration request; The processing unit is configured to execute the operation of the configuration request according to the time parameter corresponding to the type; the time parameter corresponding to the type The number is one of the multiple sets of time parameters.

14. The device according to claim 13, characterized in that The configuration request is a hibernation request in the Universal Flash Storage (UFS).

15. The device according to claim 14, characterized in that The first chip is a UFS host, and the determining unit is specifically configured to: receiving a first indication from the software layer of the Host, and determining that the type of the sleep request is a suspend sleep request Suspend H8; wherein the first indication is used to instruct sending the sleep request; or, A second indication is received from a host controller interface HCI of the Host, and it is determined that the type of the sleep request is an automatic sleep request Auto H8; the second indication is used to instruct sending a sleep request.

16. The device according to claim 14, characterized in that The first chip is a UFS host, and the determining unit is specifically configured to: receiving a third indication from a host controller interface HCI of the Host; the third indication is used to indicate that the type of the sleep request is an automatic sleep request Auto H8, or a suspended sleep request Suspend H8; Determine that the type of the sleep request is the type indicated by the third indication.

17. The device according to claim 15 or 16, characterized in that The device further comprises: The sending unit is configured to send a sleep request carrying a fourth indication to the UFS device Device, where the fourth indication is used to indicate a type of the sleep request.

18. The device according to claim 14, characterized in that The first chip is a UFS device, and the determining unit is specifically configured to: receiving the sleep request from the UFS host Host, the sleep request including a fourth indication for indicating a type; determining that the type of the sleep request is the type indicated by the fourth indication; or, Receive the sleep request from the UFS host Host, and if the UTP layer of the Device receives the SSU command, determine that the type of the sleep request is a suspend sleep request Suspend H8; if the UTP layer of the Device does not receive the SSU command, determine that the type of the sleep request is an automatic sleep request Auto H8.

19. The device according to any one of claims 13 to 18, characterized in that The device further includes an acquisition unit, configured to: After the link is established, multiple sets of time parameters configured in the second chip are obtained; Calculate the multiple groups of time parameters of the first chip according to the multiple groups of time parameters configured in the second chip.

20. The device according to any one of claims 13 to 18, characterized in that The device further comprises a configuration unit, configured to: After the link is established, multiple groups of time parameters are configured for the second chip.

21. The device according to any one of claims 13 to 18, characterized in that The device further includes a sending unit, configured to: Sending a data frame to the second chip, where the data frame includes the multiple groups of time parameters.

22. The device according to claim 21, characterized in that The data frame is PACP_CAP_EXT2_ind, or PACP_CAP_EXT1_ind, or PACP_CAP_ind.

23. The device according to any one of claims 15 to 18, characterized in that The first time parameter corresponding to the Suspend H8 is greater than the first time parameter corresponding to the Auto H8; the first time parameter is any time parameter in a group of time parameters.

24. The device according to any one of claims 13 to 23, characterized in that A set of time parameters includes one or more of T_hibern8, T_active, SaveConfigTime, StallNoConfigTime, SleepNoConfigTime, or TxTrailingClocks in the UniPro protocol.

25. A chip, characterized in that: The chip includes a memory and at least one processor, wherein the memory is used to store a set of computer instructions; when the processor executes the set of computer instructions, the operation steps of the method described in any one of claims 1 to 12 are performed.

26. A mobile terminal, characterized in that: The terminal device includes the chip as claimed in claim 25.

27. A computer-readable storage medium, characterized in that include: Computer software instructions; when the computer software instructions are executed in a computer, the computer executes the operating steps of the method described in any one of claims 1 to 12.

28. A computer program product, characterized in that When the method is executed on a computer, the computer is enabled to execute the operation steps of the method according to any one of claims 1 to 12.

Citation Information

Patent Citations

  • Method and device for determining time parameter

    CN120447975A

  • Methods and system for rapidly adjusting sleep mode and mobile terminal

    CN109302533A

  • Methods and systems for managing communication between a UFS device and a UFS host

    CN111857838A

  • Vehicle-mounted application starting method and starting device

    CN114047973A

  • Information processor, information processing method and information processing program

    JP2011039745A