Frame rate switching method and electronic device

Abstract

A frame rate switching method and electronic device are disclosed, relating to the field of terminal technology. The method includes: after the frame rate switching process begins, the SoC (System-on-a-Chip) acquires a frame rate buffer lock for the frame rate switching process, sets a frame rate switching flag to a first value, and releases the frame rate buffer lock. With the frame rate switching flag set to the first value, during the time interval during which the SoC transmits a first image to the display screen: the SoC modifies the transmission time of a second image; and the SoC sends a switching command to the display screen using the Display Serial Interface (DSI), the switching command indicating the frequency of image scanning. The SoC transmits the second image to the display screen according to the modified transmission time, and the display screen scans the second image according to the modified frequency. In this way, the modification of the transmission time and the control of the scanning frequency can be completed during the transmission of one frame of image data, avoiding screen flickering during frame rate switching and improving the display effect during frame rate switching.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a frame rate switching method and an electronic device. Background Technology

[0002] The system-on-chip (SoC) of an electronic device can transmit image data to a display screen in video mode. Furthermore, in one specific implementation within video mode, the electronic device can control the transmission time of the image data from the SoC to the display screen and the frequency at which the display screen scans the image data, thereby achieving frame rate control.

[0003] In the existing technology, the above-mentioned method of controlling the frame rate may cause screen distortion when switching frame rates, affecting the display effect. Summary of the Invention

[0004] This application provides a frame rate switching method and electronic device, which can modify the transmission time and control the scanning frequency during the transmission of a frame of image data, thereby avoiding screen tearing when switching frame rates and improving the display effect during frame rate switching.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, a frame rate switching method is provided for use in electronic devices, including system-on-a-chip (SoC) and displays. This method is primarily applied to real-time switching scenarios in video modes.

[0007] Specifically, the method includes: after the frame rate switching process (hereinafter also referred to as the frame-switching process) starts running, the SoC acquires a frame rate buffer lock (such as fps_porch_lock) for the frame rate switching process, sets the frame rate switching flag (hereinafter also referred to as the frame-switching flag) to a first value (such as true), and releases the frame rate buffer lock. With the frame rate switching flag set to the first value, during the time interval during which the SoC transmits the first image to the display screen: the SoC modifies the transmission time of the second image. For example, the SoC can modify the image transmission time by modifying the buffer (porch). Furthermore, the SoC sends a switching command to the display screen using a Display Serial Interface (DSI) (such as the Mobile Industry Processor Interface (MIPI) protocol), the switching command indicating the frequency of switching the scanning image (hereinafter also referred to as modifying the timing-table). The SoC transmits the second image to the display screen according to the modified transmission time, and the display screen scans the second image according to the modified frequency.

[0008] For example, in the following text Figure 14In the image, the first image is the second frame, and the second image is the third frame and subsequent frames.

[0009] For example, in the following text Figure 15 In the image, the first image is the third frame, and the second image is the fourth frame and subsequent frames.

[0010] For example, in the following text Figure 19 In the image, the first image is the xth frame, and the second image is the image frame after the xth frame.

[0011] For example, in the following text Figure 20 In the image, the first image is the y-th frame, and the second image is the image frame after the y-th frame.

[0012] In summary, using the embodiments of this application, after the frame rate switching process starts running, the SoC acquires a frame rate buffer lock for the frame rate switching process. Thus, after the frame rate switching process starts, other target processes (hereinafter referred to as asynchronous processes) that need to seize control of the DSI cannot hold the frame rate buffer lock. Under this premise, the SoC sets the frame-switching flag to the first value, thereby declaring that frame switching has begun, and subsequent target processes will not seize control of the DSI. Therefore, during the transmission of a frame, after the SoC modifies the transmission time, it will not be unable to send the switching command in time due to target processes seizing control of the DSI. This ensures that the modification of the transmission time and the sending of the switching command are completed within one frame, avoiding screen tearing during frame rate switching and improving the display effect during frame rate switching.

[0013] In addition, after setting the frame-cutting flag to the first value, the SoC can release the frame rate buffer lock. Subsequently, the target process can hold the frame rate buffer lock, which can reduce the blocking time of the target process, reduce resource consumption, or reduce exceptions.

[0014] In one possible design of the first aspect, after the SoC sends a switching command to the display, the method further includes: the SoC setting the frame rate switching flag to a second value.

[0015] Using this design, setting the frame rate switching flag to the second value indicates that frame switching has ended. Subsequently, the target process can seize control of the DSI to transmit relevant commands to the display screen, such as commands to send backlight and ESD discharge.

[0016] In one possible design approach of the first aspect, the method further includes: after the target process starts running, the SoC acquires a frame rate buffer lock for the target process, which is the process that needs to send commands to the display screen using DSI during its execution. After the target process ends running, the SoC releases the frame rate buffer lock. That is, the frame rate buffer lock is occupied during the time interval from the start to the end of the target process.

[0017] Furthermore, only one process can hold the frame rate buffer lock at any given time. Accordingly, the SoC acquires the frame rate buffer lock for the frame rate switching process in the following two scenarios:

[0018] When the frame rate buffer lock is released, the SoC acquires the frame rate buffer lock for the frame rate switching process. In other words, when the frame rate switching process starts running, no target process holds the frame rate buffer lock, and the SoC can acquire the frame rate buffer lock for the frame rate switching process.

[0019] When the frame rate buffer lock is held, the SoC will acquire the frame rate buffer lock for the frame rate switching process after the frame rate buffer lock is released. In other words, if the target process is already running and holding the frame rate buffer lock when the frame rate switching process starts running, the SoC must wait until the frame rate buffer lock is released, such as after the target process finishes running and releases the frame rate buffer lock, before it can acquire the frame rate buffer lock for the frame rate switching process.

[0020] This design approach ensures that only one process holds the frame rate buffer lock at any given time.

[0021] In one possible design approach of the first aspect, the SoC acquires a frame rate buffer lock for the target process, including: after setting the frame rate switching flag to a first value and releasing the frame rate buffer lock, the SoC acquires a frame rate buffer lock for the target process.

[0022] Using this design, after the SoC sets the frame rate switching flag to the first value, it can release the frame rate buffer lock, and the target process can hold the frame rate buffer lock without being blocked indefinitely.

[0023] In one possible design approach of the first aspect, after the SoC acquires the frame rate buffer lock for the target process, the method further includes: if the frame rate switching flag is at its first value, the SoC terminates the target process, such as skipping the remaining steps of the target process. This approach is mainly suitable for ESD processes or other target processes that are periodically triggered. Thus, skipping the remaining steps of the target process does not cause significant impact; for example, the display may only be affected by electrostatic discharge for a short period. Alternatively, if the frame rate switching flag is at its first value, the SoC continues running the target process after the frame rate switching flag is at its second value. This approach is mainly suitable for backlight processes or other target processes that may be triggered by the user. Thus, continuing to run the target process after the frame rate switching flag is updated to its second value only delays the response to user actions, but it ensures that user actions are responded to, preventing the user from perceiving a malfunction and improving the user experience.

[0024] In one possible design approach of the first aspect, after the SoC acquires a frame rate buffer lock for the target process, the above method further includes: if the frame rate switching flag is not a first value (such as a second value), the SoC runs the target process.

[0025] Using this design, the target process can run normally after the frame rate switching process ends or before it begins, without skipping or waiting.

[0026] In one possible design approach of the first aspect, the SoC modifies the transmission time of the second image by: before executing the code to modify the transmission time, if the SoC is transmitting the M1th row of data of the first image to the display screen, and M1 < n, that is, if the modification of the transmission time begins earlier in the current frame (first image), then the SoC modifies the transmission time of the second image while transmitting the M1th row of data of the first image. Where M1 ≥ 1, n ≥ 1, and both M1 and n are integers.

[0027] For example, in the following text Figure 14 In the diagram, line M1 is line m3.

[0028] For example, in the following text Figure 19 In the example, line M1 is line m34.

[0029] For example, in the following text Figure 20 In the example, line M1 is line m46.

[0030] By adopting this design approach, if the SoC executes the code that modifies the transmission time in the frame rate switching process early during the transmission of a frame image (the first image), the transmission time can be modified at the current time. In this way, there is enough time to execute the code that sends the switching command in the current frame, ensuring that the transmission time is modified and the switching command is sent within a frame, thus avoiding screen distortion when switching frame rates.

[0031] In one possible design approach of the first aspect, the SoC modifies the transmission time of the second image by: before executing the code to modify the transmission time, if the SoC is transmitting the M2th row of data of the third image to the display screen, and M2 > n, that is, if the modification of the transmission time begins relatively late in the current frame (the third image), the SoC delays until it begins transmitting the M3th row of data of the first image before modifying the transmission time of the second image. Where M2 ≥ 1, M3 ≥ 1, n ≥ 1, M1, M2, and n are all integers, and the third image is the frame preceding the first image.

[0032] For example, in the following text Figure 15 In the image, the third image is the second frame, the M2 line is the m6 line, the first image is the third frame, the M3 line is the m7 line, and the second image is the fourth frame.

[0033] Using this design, if the SoC executes the code to modify the transmission time during the frame rate switching process relatively late in the transmission of one frame of image (the third image), the modification of the transmission time can be delayed until after the next frame of image (the first image) begins transmission. This way, by delaying the frame rate switching by one frame, the modification of the transmission time and the sending of the switching command are ensured to be completed within the same frame, avoiding screen flickering.

[0034] In one possible design approach of the first aspect, the SoC uses a Display Serial Interface (DSI) to send a switching command to the display screen, including: the SoC sending a switching command to the display screen using the DSI while transmitting the M4th line of data of the first image. The M4th line of data is the Vertical Front Shoulder (VFP) signal.

[0035] For example, in the following text Figure 14 In the example, line M4 is line m5.

[0036] For example, in the following text Figure 15 In the text, line M4 is line m9.

[0037] For example, in the following text Figure 19 In the text, line M4 is line m38.

[0038] For example, in the following text Figure 20 In the text, line M4 is line m49.

[0039] Using this design, the SoC can send a switching command after the VFP signal arrives. This allows the display to receive the switching instruction within the VFP signal range and change the scanning frequency, avoiding interference with the scanning of the current frame.

[0040] Secondly, this application also provides an electronic device, which includes a System-on-a-Chip (SoC), a display screen, a memory, and one or more processors. The SoC, display screen, memory, and processors are coupled. The memory is used to store computer program code, which includes computer instructions. When the computer instructions are executed by the processor, they cause the electronic device to perform the method described in the first aspect and any of its possible design embodiments.

[0041] Thirdly, this application provides a chip system applied to an electronic device including a display panel and a memory; the chip system includes one or more interface circuits and one or more processors; the interface circuits and processors are interconnected via lines; the interface circuits are used to receive signals from the memory of the electronic device and send signals to the processor, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device performs the method as described in the first aspect and any of its possible design embodiments.

[0042] Fourthly, this application provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in the first aspect and any of its possible design embodiments.

[0043] Fifthly, this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method as described in the first aspect and any possible design thereof.

[0044] Understandably, the beneficial effects achieved by the electronic device of the second aspect, the chip system of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect provided above can be referred to in light of the beneficial effects of the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of the signal composition of image data provided in an embodiment of this application;

[0046] Figure 2 A waveform diagram of image data provided in an embodiment of this application;

[0047] Figure 3 A schematic diagram illustrating a frame rate switching method provided in an embodiment of this application;

[0048] Figure 4 One of the schematic diagrams for another frame rate switching method provided in the embodiments of this application;

[0049] Figure 5 A second schematic diagram illustrating another frame rate switching method provided in this application embodiment;

[0050] Figure 6 A flowchart of a backlight process is provided for an embodiment of this application;

[0051] Figure 7 A flowchart of an ESD process provided in this application embodiment;

[0052] Figure 8 An example diagram of a frame rate switching scenario provided in an embodiment of this application;

[0053] Figure 9 Example diagram of another frame rate switching scenario provided in the embodiments of this application;

[0054] Figure 10 A hardware configuration diagram of an electronic device provided in an embodiment of this application;

[0055] Figure 11A hardware and software architecture diagram of an electronic device provided in an embodiment of this application;

[0056] Figure 12 A timing interaction diagram of a frame rate switching method provided in an embodiment of this application;

[0057] Figure 13 A flowchart of a frame-slicing process provided in an embodiment of this application;

[0058] Figure 14 This application provides an example diagram illustrating frame rate switching in the current frame.

[0059] Figure 15 This application provides an example diagram illustrating a frame rate switching operation performed in the next frame.

[0060] Figure 16 A flowchart of an asynchronous process provided in an embodiment of this application;

[0061] Figure 17 A timing diagram of a frame-slicing process provided for an embodiment of this application;

[0062] Figure 18 A timing diagram of an asynchronous process provided for an embodiment of this application;

[0063] Figure 19 An example diagram illustrating frame rate switching provided in an embodiment of this application;

[0064] Figure 20 This is an example diagram illustrating another frame rate switching method provided in an embodiment of this application.

[0065] Figure 21 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0066] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0067] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0068] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0069] Before introducing the embodiments of this application, the terminology involved in the embodiments of this application will be briefly explained.

[0070] 1. Image submission mode.

[0071] Image sending mode refers to the mode in which the host sends image data to the display screen. The host can be a system-on-chip (SoC) or an application processor (AP) of an electronic device; the following explanation uses an SoC as an example.

[0072] A System-on-Chips (SoC) can send image data to a display screen via the Mobile Industry Processor Interface (MIPI) protocol of the Display Serial Interface (DSI). The MIPI protocol defines the following image transmission modes: video mode and command mode. The following section primarily describes the video mode involved in this application.

[0073] Video Mode: Similar to traditional RGB interfaces, the SoC needs to continuously refresh the display. Since no dedicated data signal is used to transmit synchronization information, control signals and RGB data are transmitted via the MIPI bus in the form of messages. Furthermore, the SoC refreshes the display periodically, eliminating the need for a frame buffer.

[0074] Command Mode: The MIPI bus controller sends pixel data streams to the display screen using display command messages. The display screen has a frame buffer for storing image data. After the image data is placed in the display screen's frame buffer, the timing controller can retrieve the image data from the frame buffer and display the image on the screen.

[0075] The frame rate switching method provided in this application is mainly applicable to the above-mentioned video modes.

[0076] 2. Transmission signals for image data in video mode.

[0077] An image frame consists of multiple rows of pixels, with each pixel's color represented using several bits of data. For example, on a monochrome display, each pixel uses 1 bit. On a 256-color display, each pixel uses 8 bits.

[0078] The SoC transmits image data to the display screen via the MIPI protocol. The following section combines... Figure 1 This section introduces the signals included in the MIPI signals used to transmit image data in video mode and their meanings.

[0079] Vertical Synchronization (VSync) signal: VSync represents the width of the vertical synchronization pulse. The Vsync signal can also be called the frame synchronization signal, used to indicate the start of a frame of data.

[0080] Horizontal Synchronization (HSync) signal: HSync represents the width of the horizontal synchronization pulse, calculated in lines. The Vsync signal, also known as the line synchronization signal, is used to indicate the start of a line of data.

[0081] Pixel clock (VCLK) signal, Figure 1 Not shown in the image: Each VCLK signal represents the data being transmitted for one pixel.

[0082] Vertical Back Porch (VBP) signal: The VBP signal indicates the number of lines that are invalid after the VSync signal at the beginning of a frame.

[0083] Vertical Front Porch (VFP) signal: The VFP signal indicates the number of invalid lines between the end of the valid line count in a frame and the next VSync.

[0084] Horizontal Back Porch (HBP) signal: The HBP signal represents the number of VCLK signals between the start of the HSync signal and the start of valid data in a line.

[0085] Horizontal Front Porch (HFP) signal: The HFP signal indicates the number of VCLK signals between the end of a line of valid data and the start of the next HSync signal.

[0086] See Figure 2 Here is an example of a MIPI waveform. Figure 2 The diagram shows the MIPI waveforms corresponding to the transmission of four image frames. Taking the transmission of the second frame as an example, a low level transmits the image information of the second frame. For example, a low level transmits... Figure 1 The image information within the vertical effective area includes the HSync, HBP, and HFP signals for the corresponding rows (effective rows) within that area. The high level consists of two parts: one part is the high level before the low level, transmitting the VSync and VBP signals; the other part is the high level after the low level, transmitting the VFP signal. Therefore, the high level does not transmit valid image data; these are invalid rows.

[0087] 3. How to switch frame rates in video mode.

[0088] For video mode, electronic devices offer the following two methods for switching frame rates:

[0089] Method 1, high switch.

[0090] Understandably, when the image frame rate changes, the time interval between the SoC processing the image and sending the image data to the display must change accordingly to meet the frame rate requirements after the switch. For example, if the frame rate before the switch is 120Hz, the SoC can process one frame of image and send the processed image to the display every 8.3ms; if the frame rate after the switch is 60Hz, the SoC can process one frame of image and send the processed image to the display every 16.6ms.

[0091] High-level switching does not change the transmission time of each line. Therefore, by changing the number of lines transmitted, the time interval for transmitting image data can be altered. Based on this, with high-level switching, the SoC can modify the number of lines of the VBP and VFP signals in the MIPI waveform (called v-porch interpolation) at the maximum frame rate, changing the transmission of invalid lines to meet the frame rate requirements after switching. For example, a higher frame rate reduces invalid lines, and a lower frame rate adds invalid lines.

[0092] For example, to change the number of rows in the VFP signal, see [link / reference]. Figure 3 The SoC transmits the second frame at a time interval of 8.3ms, corresponding to the previous frame rate of 120Hz. If VSync+VBP has 10 rows and VFP has 20 rows, the second frame has 53 valid rows, totaling 83 rows. After switching to 60Hz, the SoC transmits the third frame at a time interval of 16.6ms, twice the previous frame rate. Using high switching, the SoC can increase the number of rows in VFP from 20 to 103, while VSync+VBP remains at 10 rows, and the third frame still has 53 valid rows, totaling 166 rows. Since the transmission time per row remains unchanged, the transmission time doubles from 83 to 166 rows, perfectly meeting the time interval requirement of the new 60Hz frame rate.

[0093] In other words, after high switching is adopted, the SoC transmits image data according to the modified VBP and VFP signals, which can meet the frame rate requirements after switching.

[0094] Method 2, switch to real.

[0095] Using real switching, which doesn't change the number of lines transmitted, the time interval for transmitting image data can be altered by changing the transmission time of each line. Based on this, using high switching, the SoC can modify the number of VCLK signals in the HBP and HFP signals of each line in the MIPI waveform (also known as pulse modification), changing the transmission time of each line to meet the frame rate requirements after switching. For example, to increase the frame rate, the number of VCLK signals in the HFP signal is reduced; conversely, to decrease the frame rate, the number of VCLK signals in the HFP signal is increased.

[0096] See Figure 4 The SoC transmits the second frame at a time interval of 8.3ms, corresponding to the previous frame rate of 120Hz. If VSync+VBP has 10 lines and VFP has 20 lines, the second frame has 53 valid lines, totaling 83 lines. Therefore, the transmission time per line is (8.3 / 83)ms = 0.1ms. After switching the frame rate to 60Hz, the SoC transmits the third frame at a time interval of 16.6ms, corresponding to the new 60Hz frame rate. This time interval is twice that before the switch. Using real switching, the number of lines remains unchanged. For example, if VSync+VBP still has 10 lines and VFP still has 20 lines, the third frame still has 53 valid lines. Therefore, the transmission time per line after the switch is (16.6 / 83)ms = 0.2ms. The SoC can increase the number of VCLK signals in the HBP and HFP signals of each line, thereby changing the transmission time of each line from 0.1ms to 0.2ms. In this way, the transmission time for the same 83 lines of data is twice that before the switch, which can meet the time interval requirements corresponding to the 60Hz frame rate after the switch.

[0097] Furthermore, real-time switching is employed. By modifying the pulse, the transmission time of each line is changed. Correspondingly, the SoC sends a switching command to the display, instructing the display to switch its internal timing, essentially changing the frequency of image scanning, so that the switched timing matches the switched frame rate. For example, the display can switch the timing table of the Display Driver Integrated Circuit (DDIC) based on the switching command. The switched timing table can then scan image data based on the changed transmission time of each line, ensuring accurate scanning of each line's data even after the transmission time is changed.

[0098] In other words, by using real switching, the SoC transmits image data according to the modified transmission time of each line, and the display scans the image data according to the switched Timing Table, which can meet the frame rate requirements after the switch.

[0099] It should be noted that using high switching does not change the transmission time of each line, so the display screen can still accurately scan the data of each line using the original timing sequence.

[0100] In video mode, real frame switching can adapt to more display characteristics and requires less power compared to high frame switching, and is very likely to become the mainstream method of switching frame rates in the future.

[0101] The frame rate switching method provided in this application is mainly applicable to scenarios in video mode where the above-mentioned real switching is used to achieve frame rate switching.

[0102] During real-time switching, the SoC modifies the pulse and sends the switching command to the display within one frame. This allows the SoC to transmit data according to the transmission time of each line corresponding to the modified pulse, starting from the next frame, and the display to scan the data according to the switched timing. This avoids screen flickering.

[0103] See Figure 5 During the transmission of the second frame of data, the SoC can transmit one line of data every 0.1ms. When transmitting the m1th line of the second frame, the SoC modifies the porch (denoted as "modify" in the diagram), and when transmitting the m2th line of the second frame, the SoC sends a switching command to the display (denoted as "send" in the diagram). That is, within the transmission time of the second frame, the porch is modified and a switching command is sent. Thus, starting from the third frame, the SoC can transmit one line of data every 0.2ms, and the display can scan the data at a period of 0.2ms.

[0104] In practice, a switching command can only be successfully sent if the process (or thread, hereinafter referred to as the frame-switching process) that switches the frame rate has sole control over the DSI.

[0105] In other words, if other asynchronous processes (or threads) and the frame-switching process are vying for sole control of the DSI, such as when vying for the panel lock: if the frame-switching process successfully acquires sole control of the DSI, it can send the switching command promptly after modifying the porch, ensuring that the modification and sending of the switching command are completed within one frame; if the frame-switching process fails to acquire sole control of the DSI, even if the porch is modified earlier, the failure to acquire sole control of the DSI may cause a delay in sending the switching command, making it impossible to guarantee that the modification and sending of the switching command are completed within one frame.

[0106] For example, other asynchronous processes include, but are not limited to, the following two:

[0107] The first type is the backlight process, used to adjust the screen's display brightness.

[0108] See Figure 6 The backlight process includes the following steps:

[0109] The upper layer sends backlighting down. The upper layer can be an application or service specifically designed to control and adjust screen brightness. Specifically, in response to a user's adjustment of screen brightness or a change in ambient light, the upper layer can send backlighting down to the lower layer (such as a driver).

[0110] Set the backlight. After receiving the backlight information from the application, the underlying layer can set the backlight brightness level. For example, the `dsi-panel-set-backlight` method can be called to set the backlight brightness level.

[0111] Apply for a panel lock. After obtaining the panel lock, the backlight process can hold the panel lock and have sole control over the DSI.

[0112] Backlight is sent to the display. When the backlight process has sole control over the DSI (Diverterless Supersonic Sensor), backlight can be sent to the display via the DSI. Subsequently, the display can adjust its brightness based on the sent backlight.

[0113] Release the panel lock. After releasing the panel lock, the backlight process no longer holds the panel lock.

[0114] The second method is electrostatic discharge (ESD), which is used to reduce the impact of static electricity on screen display.

[0115] See Figure 7 The electrostatic discharge process includes the following steps:

[0116] Screen on. When the display is on, the ESD process will periodically begin.

[0117] Start the ESD process. For example, the ESD process can be started (enabled) using the sde-crtc-enable method, such as starting the ESD process every 5 seconds.

[0118] Check the connector status. The ESD process includes a method to check the connector status (sde-connector-check-status-work). Executing this method can check the DSI display status (dsi-display-check-status) and read the DSI display status register (dsi-display-status-reg-read).

[0119] Request a panel lock. After obtaining the panel lock, the ESD process can hold the panel lock and have sole control over the DSI.

[0120] Send an ESD command to the display. This ESD command is used to check whether the read DSI display status register is normal.

[0121] Release the panel lock. After releasing the panel lock, the ESD process no longer holds the panel lock.

[0122] Verify the DSI display status register. For example, the `dsi-display-validate-reg-read` method can be used. If the verification result is successful (i.e., normal), it indicates that static electricity did not affect the screen display, and the ESD start process and its subsequent steps can be repeated for the next check. If the verification result is unsuccessful (i.e., abnormal), it indicates that static electricity affected the screen display, and the following power-on steps can be performed.

[0123] Re-power on. That is, the screen can be powered off and then on again to eliminate the effects of static electricity. For example, the sde-connector-report-panel-dead method can be used to perform a re-power-on. After completing the re-power-on, the start ESD process and its subsequent procedures can be repeated for the next check.

[0124] Screen off. With the screen off, there's no need to check and eliminate the effects of static electricity through the ESD process; the ESD process can be canceled.

[0125] Cancel the ESD process. For example, you can call the dsi-bridge-disable method to cancel the ESD process.

[0126] Of course, other asynchronous processes are not limited to the backlight process and ESD process mentioned above, and will not be listed in this article.

[0127] During the time interval when other asynchronous processes have control of the DSI, such as the time interval between acquiring and releasing the panel lock, the frame-switching process cannot obtain control of the DSI, and it cannot be guaranteed that modifying the porch and sending the switching command will be completed within one frame. The following uses the ESD process as an example to illustrate two specific cases:

[0128] See Figure 8 During the transmission of the i-th frame of data:

[0129] In line m10, the ESD process begins to hold the panel lock (referred to as "holding the lock" in the diagram).

[0130] On line m11, the code that modifies porch is executed, and porch is modified.

[0131] In line m12, the ESD process releases the panel lock (referred to as "release lock" in the diagram).

[0132] On line m13, the code that sends the switching instruction is executed (referred to as the code that sends the instruction in the diagram).

[0133] Since the panel lock was released in line m12, the frame-switching process can hold the panel lock in line m14, which means it can seize control of the DSI and send switching commands.

[0134] The actual handover command is sent in line m15 after the VFP signal begins (referred to as "actually sent" in the diagram).

[0135] On line m16, the frame-slicing process can release the panel lock.

[0136] In the above Figure 8 In the example, the frame-switching process only seizes the panel lock after the ESD process releases it. There is no time conflict between the two, so the frame-switching process can hold the panel lock normally and send the switching command, thus ensuring that the modification of the porch and the sending of the switching command are completed during the transmission of the i-th frame data.

[0137] See Figure 9 During the transmission of the j-th frame of data:

[0138] On line m17, the code that modifies porch is executed, and porch is modified.

[0139] In line m18, the ESD process begins to hold the panel lock (referred to as "holding the lock" in the diagram).

[0140] At line m19, the code for sending the switching instruction is executed (referred to as "execution of the downlink code" in the diagram). Since the ESD process has not yet released the panel lock at this time, the frame-switching process can only wait for the lock to be released.

[0141] In line m20, the ESD process releases the panel lock (referred to as "lock release" in the diagram). At this point, the frame-switching process's wait for the lock to be released ends, and the switching process can request the panel lock.

[0142] See also Figure 9 During the transmission of the (j+1)th frame of data:

[0143] In line m21, the frame-switching process holds the panel lock, which means it can seize control of the DSI and use it to send switching commands.

[0144] In line m22 after the start of the VFP signal, the actual handover command is sent (referred to as "actually sent" in the diagram).

[0145] On line m23, the frame-slicing process can release the panel lock.

[0146] In the above Figure 9 In the example, during the time interval when the ESD process holds the panel lock, the frame-switching process begins to compete for the panel lock. There is a time conflict between the two, so the frame-switching process can only wait for the ESD process to release the panel lock. After the ESD process releases the panel lock, when the frame-switching process requests and holds the panel lock, the current j-th frame has already ended. Therefore, the switching command can only be sent after the VFP signal arrives in the next (j+1)-th frame. Thus, modifying the porch and sending the switching command are not completed in the same frame, causing a screen tearing issue. For example, after modifying the porch in the j-th frame, the SoC sends the data for the (j+1)-th frame according to the modified porch, such as... Figure 9 The transmission time of the (j+1)th frame of data is shorter than that of the jth frame of data. However, since the switching command is sent only in the (j+1)th frame, the display screen will still scan the data according to the original timing, resulting in a distorted screen.

[0147] It is evident that, in the presence of other asynchronous processes and frame-switching processes vying for control of the DSI, ensuring that modifying the porch and sending the switching command are completed within one frame remains a problem.

[0148] To address the aforementioned issues, this application provides a frame rate switching method. Before modifying the porch, the SoC detects whether any other asynchronous processes are currently running that could preempt control of the DSI. If no such asynchronous processes are running, the SoC declares that the frame switching process has begun, preventing other asynchronous processes from seizing control of the DSI. Then, the SoC modifies the porch and assumes control of the DSI (e.g., by holding a panel lock), sending a switching command to the display. This ensures that after modifying the porch, the switching command cannot be sent in the current frame due to other asynchronous processes assuming DSI control. Therefore, modifying the porch and sending the switching command are completed within the same frame, avoiding screen tearing and improving frame switching performance.

[0149] For example, the electronic devices in this application embodiment may be mobile phones, tablets, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, and / or smart city devices, etc., that have image processing and display requirements. This application embodiment does not impose any special limitations on the specific form of the electronic device.

[0150] See Figure 10 This is a hardware structure diagram of an electronic device. For example... Figure 10 As shown, the electronic device may include a processor 210, an internal memory 211, and a display screen 220.

[0151] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the mobile phone. In other embodiments, the mobile phone may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0152] The processor 210 may include one or more processing units, such as an application processor (AP), a modem, a central processing unit (CPU), a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), and / or a neural network processing unit (NPU).

[0153] The different processing units can be independent devices or integrated into one or more processors. For example, the AP can integrate a CPU, GPU, etc. In addition, one or more processing units in the processor 210 mentioned above, such as the AP and the Modem, can be integrated into the SoC.

[0154] In some embodiments, the processor 210 enables the electronic device to perform a frame rate switching method by executing instructions stored in the internal memory 211.

[0155] A mobile phone can achieve its display function through a GPU, a display screen 220, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 220 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering.

[0156] The display screen 220 is used to display images, videos, etc. The display screen 220 includes a display panel (also called a screen). The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, a mobile phone may include one or more display screens 220.

[0157] The display screen 220 also includes a DDIC, which may also contain a storage unit. The SoC transmits data to the DDIC in the display screen 220 via MIPI signals. After receiving the data, the DDIC can parse the data packets and obtain the data according to the MIPI protocol, then convert the digital circuitry into analog circuitry and display the image on the display panel.

[0158] It should be noted that the frame rate switching method provided in this application embodiment is applicable to scenarios involving frame rate switching in video mode. Correspondingly, the display screen 220 mainly refers to a display screen using video mode, and can also be called a video screen.

[0159] The software system of the aforementioned electronic device (such as the software system of an AP) can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture based on Android. TM Taking a system as an example, this section illustrates the software structure of an electronic device. A layered architecture divides the software system of an electronic device into several layers, each with a clear role and function, and the layers communicate with each other through software interfaces.

[0160] See Figure 11 Taking a mobile phone as an example, the hardware and software architecture of an electronic device can include the Application Layer, Application Framework Layer, Native Layer, Hardware Abstraction Layer (HAL), Kernel Layer, and Hardware Layer. Among them, the Application Layer, Application Framework Layer, Native Layer, and Hardware Abstraction Layer belong to user space, while the Kernel Layer and Hardware Layer belong to kernel space.

[0161] The application layer can accommodate various applications such as email, video player, memo, alarm clock, settings, and games. When these applications are running in the foreground, the screen can refresh to display multiple frames of images. For example, a game application can display multiple frames of game footage through screen refresh.

[0162] When applications like games and video players need to switch frame rates, they can request the underlying layer (such as the image synthesizer SF and the advanced graphics platform AGP, as mentioned below) to switch the frame rate.

[0163] In some embodiments, the application layer may also include a brightness adjustment application for adjusting the display brightness of the screen.

[0164] In some embodiments, the application layer may also include an Adaptive Power Saving (APS) module. It should be noted that APS can also be called an adaptive energy-saving module, an adaptive low-power module, etc., and this application does not specifically limit it in this way.

[0165] APS can be used to identify the current operating scenario of an electronic device and, based on this scenario, notify the underlying control layer to switch the frame rate. For example, after APS identifies (such as based on information from the Activity Manager below) that the device has transitioned from the desktop to playing a video through a video player, it can notify the underlying layer to perform a frame rate switch.

[0166] APS can also be used to adjust the frame rate based on the temperature of the electronic device. For example, the frame rate can be limited in high-temperature conditions.

[0167] The application framework layer provides the application programming interface (API) and programming framework for the application layer. The application framework layer includes some predefined functions.

[0168] For example, the application framework layer may include system services such as window manager, activity manager, and resource manager.

[0169] The native layer provides various services to the upper layers (such as the application framework layer). The native layer may include advanced graphics platform (AGP), image compositor (SurfaceFlinger, SF), etc.

[0170] AGP can be used for frame rate management, refresh rate adjustment, etc. For example, AGP can determine the frame rate level (i.e., determine the frame rate) based on the current operating scenario of the electronic device and send the determined frame rate to the image synthesizer.

[0171] The SurfaceFlinger (SF) image compositer can be used for layer compositing, backlighting, screen brightness control, etc. It should be noted that the image compositer can also be translated as a surface thrower, surface drawing module, image compositing processing service, etc., and this application does not specifically limit it to these terms.

[0172] The image synthesizer can also control frame rate switching based on frame rate information sent by the application or AGP, such as notifying the display driver to switch the frame rate.

[0173] The Hardware Abstraction Layer (HAL) can encapsulate kernel-level drivers, providing calling interfaces to higher layers. The HAL can include a Hardware Composer (HWC). The HWC can be used for image compositing processing and for providing the composited image data to the display driver. It should be noted that image data obtained from GPU-composited images can also be provided to the display driver via the HWC.

[0174] HWC can also be used to transfer frame rate control information between the image synthesizer and the underlying driver.

[0175] The kernel layer (also known as the driver layer) contains the drivers that make the hardware work. Specifically, the kernel layer includes the display driver.

[0176] The display driver can be used to send the synthesized image data to a display screen for display, such as via a MIPI signal. In some embodiments, the display driver can also modify the porch and send switching commands based on the switched frame rate.

[0177] The hardware layer may include hardware such as CPU, GPU, and display screen (further including display panel, DDIC).

[0178] Let's combine the following... Figure 12 The following is an exemplary illustration of the interaction process of the various software and hardware modules in the frame rate switching method provided in the embodiments of this application:

[0179] When there is a need for frame switching, S1201 and APS / other applications send a notification to the image synthesizer to switch the frame rate.

[0180] For example, after the APS recognizes a frame rate switching scenario, such as when the temperature of the electronic device exceeds a preset temperature, or when it switches from displaying the desktop to displaying a video playback window, there is a frame rate switching requirement, and it can send a frame rate switching notification to the image synthesizer.

[0181] For example, when other applications such as video players and games detect that the conditions for frame rate switching are met, such as playing a high frame rate video or receiving a user's operation to switch the game frame rate, there is a frame rate switching requirement, and they can send a frame rate switching notification to the image synthesizer.

[0182] It should be noted that APS and / or other applications can send frame rate switching notifications to the image synthesizer via AGP.

[0183] The frame rate switching notification may include information indicating the frame rate after the switch, such as the frame rate after the switch or the identified scene.

[0184] S1202, The image synthesizer sends the switched frame rate to the display driver.

[0185] It should be noted that the image compositor can send the switched frame rate to the display driver via a hardware compositor.

[0186] S1203, the display driver modifies the pulse based on the switched frame rate.

[0187] S1204, The display driver sends a switching command to the display screen based on the switched frame rate.

[0188] The above S1203 and S1204 belong to the frame-switching process. Furthermore, the display driver can only execute S1204 and send the switching command after gaining control of the DSI.

[0189] S1205, The display screen modifies the timing table based on the switching command.

[0190] The frame rate switching method provided in this application embodiment, before modifying the porch (e.g., before executing S1203 above): the SoC can first request a frame rate buffer lock (denoted as fps-porch-lock). If the frame rate buffer lock can be obtained, it indicates that no other asynchronous process is running that would preempt control of the DSI. When no other asynchronous process is currently occupying control of the DSI, the SoC can set the frame switching flag (denoted as fps-enable) to its first value to declare that frame switching has begun, preventing other asynchronous processes from preempting control of the DSI. Next, the SoC modifies the porch (e.g., executing S1203 above). Then, the SoC occupies control of the DSI (e.g., holds a panel lock) and sends a switching command to the display screen (e.g., executing S1204 above).

[0191] For details, see Figure 13 The process switching includes the following steps. Figure 13 The execution entity for each step is the SoC, such as the display driver in the SoC, which will not be elaborated on further below.

[0192] S1301, Request a frame rate buffer lock.

[0193] After the frame-slicing process begins, a frame rate buffer lock will be requested for the frame-slicing process.

[0194] At this point, it should be noted that if a process contains code that requests locks (including frame rate buffer locks, panel locks, etc.), the process can request the corresponding lock when it starts running and executes the code that requests a lock. This process request can also be understood as the SoC or display driver requesting a lock for the process.

[0195] S1302. Check if a frame rate buffer lock has been acquired. If yes, execute S1303 and subsequent steps; otherwise, the frame switching process is blocked.

[0196] Only one process can hold the frame rate buffer lock at any given time. If another asynchronous process holds the frame rate buffer lock, it means that another asynchronous process has preempted control of the DSI and cannot acquire the frame rate buffer lock for the frame-switching process. If no other asynchronous process holds the frame rate buffer lock, it means that no other asynchronous process has preempted control of the DSI and can acquire the frame rate buffer lock for the frame-switching process.

[0197] For details on the specific implementation of other asynchronous processes requesting and holding frame rate buffer locks, please refer to the following text. Figure 16 The relevant explanations will not be discussed in detail here.

[0198] If a frame rate buffer lock is acquired for the frame-slicing process, the frame-slicing process can continue to complete, such as executing S1303 and subsequent steps.

[0199] If a frame rate buffer lock is not acquired for the frame-slicing process, the frame-slicing process will be blocked and will need to wait for the frame rate buffer lock to be released before it can be acquired and the frame-slicing process can continue, such as executing S1303 and subsequent steps.

[0200] S1303, Set the frame-cutting flag to the first value.

[0201] The first value can be 1, true, etc., and this application embodiment does not specifically limit it.

[0202] Setting the frame-slicing flag to its first value indicates that frame-slicing has begun. In this case, other asynchronous processes will not seize control of DSI.

[0203] S1304, Release the frame rate buffer lock.

[0204] After releasing the frame rate buffer lock, other asynchronous processes can hold the frame rate buffer lock, thereby reducing the blocking time of other asynchronous processes. At the same time, with the frame-switching flag set to its first value, other asynchronous processes cannot preempt control of the DSI. This ensures that the possibility of preempting control of the DSI is reserved only for the frame-switching process before the porch is modified, preventing the inability to send switching commands within the same frame due to other asynchronous processes preempting control of the DSI after the porch is modified.

[0205] S1305, Modify porch.

[0206] For example, HBP and HFP can be modified to change the transmission time of a line, thereby achieving the purpose of switching the frame rate.

[0207] S1306, Apply for panel lock.

[0208] Applying for a panel lock allows you to seize control of the DSI.

[0209] S1307. Check if a panel lock has been acquired. If yes, proceed to S1308 and subsequent steps; otherwise, the frame-switching process is blocked.

[0210] At any given time, only one process can acquire the panel lock and thus have sole control over the DSI.

[0211] At this point, it should be noted that: after the aforementioned S1301-S1304, a frame rate buffer lock was acquired for the frame-switching process, meaning no other asynchronous process could potentially seize control of the DSI. Furthermore, setting the frame-switching flag to its first value prevents other asynchronous processes from preempting control of the DSI. In other words, theoretically, when executing S1307, no other asynchronous process currently holds the panel lock to gain control of the DSI; therefore, the detection result of S1307 is positive. However, in S1307, the check for acquired panel locks can reuse the existing frame-switching process code, reducing code modifications and ensuring compatibility with unknown abnormal scenarios.

[0212] If a panel lock is obtained for the frame-switching process, the frame-switching process can continue, such as executing S1308 and subsequent steps.

[0213] If a panel lock is not acquired for the frame-switching process, the frame-switching process will be blocked and will need to wait for the panel lock to be released before it can be acquired and the frame-switching process can continue, such as by executing S1308 and subsequent steps.

[0214] S1308, Send switching command.

[0215] While the frame-switching process holds the panel lock, a switching command can be sent to the display screen.

[0216] For example, a switching command can be sent after the VFP signal arrives.

[0217] S1309, Release panel lock.

[0218] After the panel lock is released, other asynchronous processes can hold the panel lock and send corresponding commands to the display, such as commands to send backlight or ESD.

[0219] S1310, Set the frame-cutting flag to the second value.

[0220] The second value can be 0, false, etc., and this application does not specifically limit it.

[0221] Setting the frame-splitting flag to the second value indicates that frame-splitting has ended. In this case, other asynchronous processes can then seize control of DSI.

[0222] use Figure 13 In this embodiment, before the porch modification begins, other asynchronous processes cannot preempt control of the DSI. Thus, after the porch modification, the frame-switching process can successfully seize control of the DSI and send the switching command. This ensures that the porch modification and switching command sending are performed within the same frame.

[0223] Furthermore, when modifying the porch, the SoC can also use a trigger line scheme to avoid the modification of the porch and the sending of the switching command not being completed in the same frame due to the modification time being too late, and further ensure that the modification of the porch and the sending of the switching command are completed in the same frame.

[0224] The trigger line is the nth row of a frame of data in the MIPI signal, where n ≥ 1 and n is an integer. n is related to the time T1 required from executing the code that modifies the porch to executing the code that sends the switching command. The longer the time T1, the smaller n is; the shorter the time T1, the larger n is.

[0225] Specifically, the SoC can only send a switching command to the display within the VFP signal. Therefore, the interval between the nth row and the VFP signal is as follows: Figure 14 The duration T2 in the first time interval is greater than the duration T1.

[0226] See also Figure 14 If the SoC executes the code to modify the porch in line m3, before line n, it indicates that the porch modification in line m3 is relatively early, ensuring that the handover command is sent in the VFP signal within the current frame (frame 2 in the diagram). Based on this, when the current line m3 < n when the code to modify the porch is executed, the SoC can execute the code to modify the porch in line m3, completing the modification, such as modifying HFP and HBP in each line. Then, in line m4, before the VFP signal arrives, it can execute the code to send the handover command (referred to as "execute the sending code" in the diagram), completing the preparations before sending the handover command, and then sending the handover command in the VFP signal, such as in line m5 (referred to as "actually sent" in the diagram). Thus, the porch can be modified and the handover command can be sent within the current frame.

[0227] See Figure 15If the SoC executes the code to modify the porch in line n or later, specifically line m6 (denoted as planned modification in the diagram), it indicates that the porch modification in line m6 is too late. Subsequently, the code to send the handover command may not be executed until after the VFP signal arrives, making it difficult to guarantee that the handover command will be sent within the VFP signal in the current frame (frame 2 in the diagram). Therefore, when the current line m6 ≥ n when the code to modify the porch is executed, the SoC can choose not to execute the porch modification code in line m6. Instead, it can delay until after the VSync signal arrives in the next frame (frame 3 in the diagram), such as line m7, to execute the porch modification code (denoted as actual modification in the diagram). Then, in line m8, before the VFP signal arrives, it executes the code to send the handover command (denoted as execution of the sending code in the diagram), completing the preparations before sending the handover command. Finally, in the VFP signal, such as line m9, it sends the handover command (denoted as actual sending in the diagram). This is equivalent to delaying the frame rate switching by one frame, ensuring that the porch modification and handover command can be completed within the same frame.

[0228] See Figure 16 To accommodate the above frame-slicing process, asynchronous processes such as the backlight process and ESD process may include the following steps. Figure 16 The execution entity for each step is the SoC, such as the display driver in the SoC, which will not be elaborated on further below.

[0229] S1601, Request a frame rate buffer lock.

[0230] After the asynchronous process starts, a frame rate buffer lock will be requested for the asynchronous process.

[0231] S1602. Check if a frame rate buffer lock has been acquired. If yes, execute S1603 and subsequent steps; otherwise, the asynchronous process is blocked.

[0232] Only one process can hold the frame rate buffer lock at any given time. If another process (such as the frame-switching process or an asynchronous process other than the current asynchronous process) holds the frame rate buffer lock, it indicates that another process has started running and may preempt control of the DSI. For example, in the stage from the "Yes" branch in S1302 of the frame-switching process to S1304, it is impossible to acquire the frame rate buffer lock for the current asynchronous process. If no other process holds the frame rate buffer lock, it is possible to acquire the frame rate buffer lock for the current asynchronous process.

[0233] If a frame rate buffer lock is acquired for the asynchronous process, the asynchronous process can continue to complete, such as executing S1603 and its subsequent steps.

[0234] If a frame rate buffer lock is not acquired for the asynchronous process, the asynchronous process will be blocked and will need to wait for the frame rate buffer lock to be released before it can be acquired and continue to complete the asynchronous process, such as executing S1603 and subsequent steps.

[0235] S1603. Check if the frame-cutting flag is the first value.

[0236] Based on the preceding text Figure 13 As can be seen from the introduction, the frame-switching flag is at its first value after S1303 and before S1310 in the frame-switching process.

[0237] If the frame-switching flag is not the first value, it indicates that no frame is being switched, such as no porch is being modified or a switching command is being sent. The current asynchronous process can then take control of the DSI and execute S1604-S1608 as described below.

[0238] If the frame-cutting flag is detected to be at its first value, it indicates that frame cutting has begun. The current asynchronous process cannot seize control of DSI, so the remaining process of the asynchronous process can be skipped, such as skipping S1604-S1607 and directly executing S1608 below.

[0239] Of course, in other embodiments, when the frame-cutting flag is at the first value, it is also possible to wait for the frame-cutting flag to be updated to the second value, and after the frame-cutting flag is updated to the second value, the remaining process of the asynchronous process can continue to be executed, such as executing S1604-S1607.

[0240] In one specific implementation, for the case where the frame-cutting flag is the first value, different processing methods can be adopted based on the different asynchronous processes.

[0241] For example, if the asynchronous process is an ESD process, then when the frame-cutting flag is set to the first value, the remaining process of the asynchronous process can be skipped, meaning the current ESD process will not continue. Since the ESD process is triggered periodically when the screen is on, such as every 5 seconds, skipping the remaining process of the ESD process will not cause a significant impact; for example, the display may only be affected by static electricity for a short period of time.

[0242] For example, if the asynchronous process is the backlight process, then when the frame-switching flag is at the first value, it can wait for the frame-switching flag to be updated to the second value. After the frame-switching flag is updated to the second value, the remaining process of the backlight process can continue to complete the adjustment of the display brightness. Since the backlight adjustment may be triggered by the user, in this case, waiting for the frame-switching flag to be updated to the second value before continuing to execute the backlight process can ensure that it responds to the user's operation and does not make the user feel that the backlight adjustment has failed.

[0243] S1604, Apply for panel lock.

[0244] Applying for a panel lock allows you to seize control of the DSI.

[0245] S1605. Check if a panel lock has been acquired. If yes, proceed to S1606 and subsequent steps; otherwise, the asynchronous process is blocked.

[0246] At any given time, only one process can acquire the panel lock and thus have sole control over the DSI.

[0247] Therefore, it's important to note that after steps S1601-S1603, the panel lock is only requested for the current asynchronous process if no other process holds the frame rate buffer lock and the frame-switching flag is at its second value. This prevents other processes from seizing control of the DSI. In other words, theoretically, when S1605 is executed, no other asynchronous process holds the panel lock to gain control of the DSI, meaning the detection result of S1605 is positive. However, in S1605, the check for acquired panel locks can reuse existing asynchronous process code, reducing code modifications and ensuring compatibility with unknown exceptions.

[0248] If a panel lock is acquired for the current asynchronous process, the asynchronous process can continue, such as executing S1606 and its subsequent steps.

[0249] If a panel lock is not acquired for the current asynchronous process, the current asynchronous process will be blocked and will need to wait for the panel lock to be released before it can acquire a panel lock and continue the asynchronous process, such as executing S1606 and subsequent steps.

[0250] S1606, Send commands related to asynchronous processes.

[0251] For example, if the asynchronous process is an ESD process, then an ESD command can be sent to the display screen.

[0252] For example, if the asynchronous process is a backlight process, then it can send backlight to the display screen.

[0253] S1607, Release panel lock.

[0254] After the panel lock is released, other processes can hold the panel lock and send corresponding commands to the display screen.

[0255] S1608, Release the frame rate buffer lock.

[0256] In this way, after the asynchronous process ends, a frame rate buffer lock can be requested for other processes (such as the frame-switching process).

[0257] use Figure 16 In this embodiment, a panel lock can only be requested for the asynchronous process when there is no frame switching in progress, such as when the frame switching flag is set to the second value before the porch is modified or after the switching command is sent. This ensures that the timing of sending the switching command will not be affected after the porch is modified, and that the switching command is sent in a timely manner after the porch is modified.

[0258] In summary Figure 13 and Figure 16 Example: See Figure 17 During the period from when the frame-switching process begins and holds the frame rate buffer lock until it releases it, the asynchronous process cannot hold the frame rate buffer lock, thus preventing it from further attempting to seize control of the DSI. Similarly, during the period from when the frame-switching flag is set to its first value until it is updated to its second value, the asynchronous process also cannot seize control of the DSI. Therefore, from the start of the frame-switching process and its holding of the frame rate buffer lock until the modification of the porch and the sending of the switch command are completed, the asynchronous process cannot seize control of the DSI, ensuring that the switch command is sent promptly after the porch modification. Furthermore, releasing the frame rate buffer lock promptly before modifying the porch and after setting the frame-switching flag to its first value allows the asynchronous process to hold the lock, reducing the blocking time of the asynchronous process, minimizing resource waste caused by blocking, and reducing the possibility of exceptions.

[0259] See Figure 18 If the frame-switching process cannot hold the frame rate buffer lock during the period from when the asynchronous process holds the frame rate buffer lock to when it releases the frame rate buffer lock, it will not proceed with the steps of modifying the porch and sending the switching command. This avoids the inability to send the switching command in time after modifying the porch due to the inability to seize control of the DSI.

[0260] The following examples will further explain this. Figure 17 and Figure 18 Effect:

[0261] Example 1: After the frame-slicing process begins, the ESD process begins, as described above. Figure 9 Example correspondence.

[0262] See Figure 19 During the transmission of the xth frame of data:

[0263] After the frame-switching process starts, a frame rate buffer lock is requested for the frame-switching process in line m30. Since the ESD process has not started yet, the frame-switching process can successfully hold the frame rate buffer lock, which is denoted as "holding lock 1" in the figure.

[0264] In line m31, the frame cut flag is set to the first value, which is denoted as "set" in the figure.

[0265] In line m32, the frame rate buffer lock of the frame-switching process is released, which is denoted as Release Lock 1 in the figure.

[0266] Between lines m30 and m32, the ESD process has already started, but it is blocked because the frame-slicing process holds the frame rate buffer lock. In line m33, the ESD process successfully acquires the frame rate buffer lock (referred to as "lock holding 1" in the diagram). Therefore, setting the frame-slicing flag to the first value releases the frame rate buffer lock, allowing the ESD process to terminate its blocking and preventing it from being blocked until the entire frame-slicing process completes, thus reducing the blocking time of the ESD process.

[0267] Furthermore, in line m31, before line m33, the frame-switching flag is set to its first value, preventing the ESD process from seizing control of the DSI. Correspondingly, in line m33, after the ESD process acquires the frame rate buffer lock, if it detects the frame-switching flag is at its first value, it can skip the remaining steps of the ESD process and release the frame rate buffer lock held by the ESD process, such as releasing the frame rate buffer lock in line m37 (referred to as "Lock Release 1" in the diagram). It should be noted that the timing of releasing the frame rate buffer lock held by the ESD process in the diagram is just an example; in reality, it could be any point in time after line m33 and after skipping the remaining steps.

[0268] In line m34, the code that modifies porch is executed, and porch is modified. Furthermore, porch is only modified in line m34 if m34 < n; otherwise, the modification is delayed until the next frame. This prevents the modification of porch and the sending of the switching command from being unable to be completed within the same frame due to a late modification. Figure 19 The example mainly uses the case where m34 < n.

[0269] In line m35, a panel lock is requested for the frame-switching process. Since the frame-switching flag is at its first value at this time, the ESD process cannot seize control of the DSI. Therefore, the frame-switching process can successfully hold the panel lock, which is denoted as "holding lock 2" in the figure.

[0270] In line m36, the code for sending the switching command is executed, denoted as "execution of the sending code" in the diagram. Since the frame-switching process holds the panel lock at this time, it can send the switching command. Then, in line m38 after the VFP signal arrives, the actual switching command is sent, denoted as "actual sending" in the diagram.

[0271] In line m39, the panel lock of the frame-switching process is released, which is denoted as Release Lock 2 in the figure.

[0272] In line m40, the frame-cutting flag is restored to its initial second value, which is denoted as reset in the figure.

[0273] In the above Figure 19 In the example, after the frame-switching process begins, the ESD process starts. However, because the frame-switching flag was set to the first value before the porch was modified, the ESD process cannot seize control of the DSI. Therefore, after modifying the porch, the ESD process will not seize control of the DSI, preventing the sending of a handover command within the current x-th frame, thus ensuring that both porch modification and handover command sending occur within the same frame.

[0274] It should be noted that, Figure 19 In the example where the ESD process starts before the frame-switching process modifies the porch, the frame-switching process still holds the frame rate buffer lock. In some examples, the ESD process may start after the porch is modified, at which point the frame-switching process has already released the frame rate buffer lock. In this case, the ESD process will not be blocked and can hold the frame rate buffer lock promptly after the ESD process starts. However, it may still be unable to gain control of DSI later because the frame-switching flag is at its first value, and thus may skip the remaining ESD process.

[0275] Example 2: Start the ESD process before starting the frame-slicing process.

[0276] See Figure 20 During the transmission of the y-th frame of data:

[0277] After the ESD process starts, a frame rate buffer lock is requested for the ESD process on line m41. Since the frame switching process has not started yet, the ESD process can successfully hold the frame rate buffer lock, which is marked as "holding lock 1" in the figure.

[0278] Next, in line m42, the relevant commands for sending the ESD process are completed, and the frame rate buffer lock of the ESD process can be released, which is marked as releasing lock 1 in the diagram. It can be understood that between lines m41 and m42, a panel lock will be requested for the ESD process, so that the ESD process can obtain control of DSI and thus transmit the relevant commands of the ESD process, which will not be elaborated here.

[0279] Between lines m41 and m42, the frame-slicing process has already begun. However, because the ESD process holds the frame rate buffer lock, the frame-slicing process is blocked. In the subsequent line m43, the frame-slicing process successfully acquires the frame rate buffer lock (marked as lock holding 1 in the diagram), at which point the frame-slicing process ends and is blocked again.

[0280] In line m44, the frame cut flag is set to the first value, which is denoted as "set" in the figure.

[0281] In line m45, the frame rate buffer lock of the frame-switching process is released, which is denoted as Release Lock 1 in the figure.

[0282] In line m46, the code that modifies porch is executed, and porch is modified. Furthermore, porch is only modified in line m46 if m46 < n; otherwise, the modification is delayed until the next frame. This is particularly effective for... Figure 20 As shown, if the ESD process starts before the frame-switching process, the porch modification will not be delayed due to the frame-switching process being blocked, thus preventing the modification of the porch and the sending of the switching command from being completed within the same frame.

[0283] In line m47, a panel lock is requested for the frame-switching process. Since the frame-switching flag is at its first value at this time, even if the ESD process is triggered again, it will not be able to seize control of the DSI. Therefore, the frame-switching process can successfully hold the panel lock, which is recorded as "holding lock 2" in the figure.

[0284] In line m48, the code for sending the switching command is executed, denoted as "execution of the sending code" in the diagram. Since the frame-switching process holds the panel lock at this time, it can send the switching command. Then, in line m49 after the VFP signal arrives, the actual switching command is sent, denoted as "actual sending" in the diagram.

[0285] In line m50, the panel lock of the frame-switching process is released, which is denoted as release lock 2 in the figure.

[0286] In line m51, the frame-cutting flag is restored to its initial second value, which is denoted as reset in the figure.

[0287] In the above Figure 20 In the example, if the ESD process starts before the frame-switching process begins, the steps of modifying the porch and sending the handover command in the frame-switching process will begin after the ESD process ends and releases the frame rate buffer lock. This ensures that the ESD process, which starts earlier, will not further affect the sending of the handover command after modifying the porch, guaranteeing that both porch modification and handover command sending are performed within the same frame.

[0288] Furthermore, before modifying the porch, the frame-switching flag is set to its first value. This ensures that even if the ESD process is triggered again later, it cannot seize control of the DSI, guaranteeing that the porch can be modified and the handover command sent within the same frame.

[0289] This application also provides an electronic device, which may include a memory and one or more processors (such as a CPU, GPU, NPU, etc.). The memory and processor are coupled. The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device can perform various functions or steps performed by the device in the above method embodiments.

[0290] This application also provides a chip system, such as... Figure 21 As shown, the chip system 2100 can be a SoC (System-on-a-Chip), which may include at least one processor 2101 and at least one interface circuit 2102. The processor 2101 and the interface circuit 2102 can be interconnected via lines. For example, the interface circuit 2102 can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit 2102 can be used to send signals to other devices (e.g., the processor 2101). Exemplarily, the interface circuit 2102 can read instructions stored in memory and send those instructions to the processor 2101. When the instructions are executed by the processor 2101, the electronic device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in this application embodiment.

[0291] This application also provides a chip system including at least one processor and at least one interface circuit. The processor and the interface circuit are interconnected via lines. For example, the interface circuit can be used to receive signals from other devices (e.g., the memory of an electronic device). As another example, the interface circuit can be used to send signals to other devices (e.g., the processor). Exemplarily, the interface circuit can read instructions stored in the memory and send the instructions to the processor. When the instructions are executed by the processor, the electronic device can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application does not specifically limit this.

[0292] This embodiment also provides a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the image processing method described above.

[0293] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the image processing method described above.

[0294] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component, or module. The apparatus may include a connected processor and a memory; wherein the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the image processing methods in the above-described method embodiments.

[0295] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding method provided above, and will not be repeated here.

[0296] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to 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.

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

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

[0299] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0300] If the integrated unit is implemented as 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 solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0301] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application.

Claims

1. A frame rate switching method, characterized in that, Applied to an electronic device, the electronic device including a system-on-a-chip (SoC) and a display screen, the method includes: After the frame rate switching process starts running, the SoC requests a frame rate buffer lock for the frame rate switching process, sets the frame rate switching flag to the first value, and releases the frame rate buffer lock. When the frame rate switching flag is at the first value, during the time interval when the SoC transmits the first image to the display screen: the SoC modifies the transmission time of the second image, and the SoC sends a switching command to the display screen using the Display Serial Interface (DSI), the switching command indicating the frequency of switching the scan image; The SoC transmits the second image to the display screen according to the modified transmission time, and the display screen scans the second image according to the modified frequency.

2. The method according to claim 1, characterized in that, After the SoC sends a switching command to the display, the method further includes: The SoC sets the frame rate switching flag to a second value.

3. The method according to claim 1 or 2, characterized in that, The method further includes: After the target process starts running, the SoC requests the frame rate buffer lock for the target process, which is the process that needs to send commands to the display screen using DSI during the running process; After the target process finishes running, the SoC releases the frame rate buffer lock; The SoC requests a frame rate buffer lock for the frame rate switching process, including: When the frame rate buffer lock is released, the SoC acquires the frame rate buffer lock for the frame rate switching process; When the frame rate buffer lock is occupied, the SoC requests the frame rate buffer lock for the frame rate switching process after the frame rate buffer lock is released.

4. The method according to claim 3, characterized in that, The SoC requests the frame rate buffer lock for the target process, including: After setting the frame rate switching flag to the first value and releasing the frame rate buffer lock, the SoC requests the frame rate buffer lock for the target process.

5. The method according to claim 3 or 4, characterized in that, After the SoC acquires the frame rate buffer lock for the target process, the method further includes: If the frame rate switching flag is the first value, the SoC terminates the execution of the target process; or, If the frame rate switching flag is at the first value, the SoC continues to run the target process after the frame rate switching flag is at the second value.

6. The method according to any one of claims 3-5, characterized in that, After the SoC acquires the frame rate buffer lock for the target process, the method further includes: If the frame rate switching flag is not the first value, the SoC runs the target process.

7. The method according to any one of claims 1-6, characterized in that, The SoC modifies the transmission time of the second image, including: Before executing the code that modifies the transmission time, if the SoC transmits the M1th row of data of the first image to the display screen and M1 < n, the SoC modifies the transmission time of the second image while transmitting the M1th row of data of the first image; Where M1≥1, n≥1, and M1 and n are both integers.

8. The method according to any one of claims 1-6, characterized in that, The SoC modifies the transmission time of the second image, including: Before executing the code that modifies the transmission time, if the SoC is transmitting the M2th row of data of the third image to the display screen and M2 > n, the SoC delays until it starts transmitting the M3th row of data of the first image and then modifies the transmission time of the second image. Where M2≥1, M3≥1, n≥1, M1, M2 and n are all integers, and the third image is the frame preceding the first image.

9. The method according to any one of claims 1-8, characterized in that, The SoC sends switching commands to the display screen using the Display Serial Interface (DSI), including: When the SoC is transmitting the M4th line of data of the first image, it uses the DSI to send the switching command to the display screen; Among them, the data in the M4th row is the vertical front shoulder VFP signal.

10. An electronic device, characterized in that, include: A display panel, one or more processors, and one or more memories; the one or more processors are coupled to the display panel and the one or more memories; the one or more memories are used to store computer program code, the computer program code including computer instructions that, when the one or more processors execute the computer instructions, cause the electronic device to perform the method as described in any one of claims 1-9.

11. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the computer instructions are executed on the electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-9.

12. A computer program product comprising computer instructions, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-9.

Images