Method and system for releasing amount of space from shared buffer

Abstract

The invention relates to a method and system for releasing an amount of space from a shared buffer. A system includes a display subsystem (100). The display subsystem includes a shared buffer (108) having allocation portions, each allocation portion being allocated to one of a plurality of display threads (Thread 1, Thread 2, Thread 3), each display thread being associated with a display peripheral (116a to 116d). The display subsystem also includes a direct memory access (DMA) engine (106) configured to receive, from a host processor (150), a request to release an amount of space from a first allocation portion associated with a first display thread. In response to receiving the request, the DMA engine releases the amount of space from the first allocation portion and shifts the allocation portions of at least some of the other display threads to maintain contact of the allocation portions and join free space at the end of the shared buffer.

Description

[0001] Information about divisional applications

[0002] This case is a divisional application. The parent case of the divisional application is an invention patent application with application date of December 25, 2019, application number 201911360651.0, and invention name “Method and system for releasing space from a shared buffer”. Technical Field

[0003] Embodiments of the present application relate to a method and system for releasing an amount of space from a shared buffer. Background Art

[0004] The emergence of multi-display systems with increased display resolutions and frame rates presents challenges for effectively and efficiently controlling the various displays. For example, in an in-vehicle application, a single display subsystem may be responsible for displaying different content on multiple display peripherals, such as an instrument cluster display, a passenger monitor, and a rear seat entertainment display. The display subsystem extracts display content data from memory for each of the display peripherals, performs processing (e.g., color space conversion, video format conversion, resizing) and compositing functions on the content data to generate display frames, and transmits the frames to the correct display peripherals for viewing by one or more users. Summary of the invention

[0005] According to at least one example of the present disclosure, a system includes a display subsystem. The display subsystem includes a shared buffer having allocation portions, each allocation portion being allocated to one of a plurality of display threads, each display thread being associated with a display peripheral device. The display subsystem also includes a direct memory access (DMA) engine configured to receive a request from a host processor to release an amount of space from a first allocation portion associated with a first display thread. In response to receiving the request, the DMA engine releases the amount of space from the first allocation portion and shifts the allocation portions of at least some of the other display threads to keep the allocation portions touching and concatenate free space at the end of the shared buffer.

[0006] According to another example of the present disclosure, a method includes receiving a request from a host processor to release an amount of space from a first allocated portion of a shared buffer associated with a first display thread. Each allocated portion of the shared buffer is allocated to one of a plurality of display threads and each display thread is associated with a display peripheral device. In response to receiving the request to release, the method includes releasing the amount of space from the first allocated portion and shifting allocated portions of at least some of the other display threads to keep the allocated portions touching and concatenating free space at the end of the shared buffer. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] To describe various examples in detail, reference will now be made to the accompanying drawings, in which:

[0008] Figure 1 showing a block diagram of a system according to various examples;

[0009] Figure 2 An exemplary graph showing buffer requirements for various video resolutions, formats, and access and usage patterns according to various examples;

[0010] Figure 3 Demonstrating an exemplary memory allocation process according to various examples;

[0011] Figure 4 showing flowcharts of methods according to various examples; and

[0012] Figure 5 Demonstrate additional security and confidentiality access permissions based on various examples Figure 1 Block diagram of the . DETAILED DESCRIPTION

[0013] Reducing or minimizing latency in the display subsystem is important, especially when some display content is safety-critical (e.g., instrument cluster data, live feeds from one or more external cameras). To address latency issues, the display subsystem performs the aforementioned processing and synthesis functions inline. A non-inline alternative involves first processing / synthesizing the display frame, writing the display frame back to memory, and then extracting the display frame for display. Although the inline display subsystem approach reduces latency, this approach also increases local buffering requirements relative to the non-inline approach to ensure that sufficient data is available for processing into display frames. In other words, an insufficiently sized local buffer results in frames being discarded when using the inline display subsystem. In addition, buffering requirements increase with screen resolution; however, it is inefficient to allocate a buffer of sufficient size for each display to handle the largest currently available resolution. Also, higher resolution display formats developed in the future are not supported due to insufficient buffer size.

[0014] Examples of the present disclosure solve the aforementioned problems by providing an inline display subsystem and method in which space in a shared local buffer is dynamically allocated to multiple display threads and to multiple channels within a display thread. A channel corresponds to a single source of display data, while a thread refers to one or more channels associated with a specific display device.

[0015] The main processor executes supervisory software (e.g., a hypervisor), and one or more host processors are coupled to the main processor. The host processor generates content for ultimate display on one or more of the display peripherals. The host processor requests the main processor to increase or decrease the size of a shared buffer allocated to a thread or channel associated with the host processor, and the host processor itself increases or decreases the size of a shared buffer allocated to a channel associated with the host processor.

[0016] Supervisory software controlling the overall display subsystem determines that reallocation should occur, for example, because the resolution of a particular thread increases (or may increase), and another thread is not utilizing all of its allocated buffer space or is able to have its allocated buffer space reduced (e.g., due to a reduction in resolution of the second thread). Similarly, in some examples, supervisory software or a host processor managing its associated threads determines that reallocation should occur because, within a thread, the resolution of a particular channel increases (or may increase), and another channel in the same thread is not utilizing all of its allocated buffer space or is able to have its allocated buffer space reduced (e.g., due to a reduction in resolution of the second channel). In some examples, reallocation of additional space to a particular channel occurs because there is unused space allocated for the thread with which the channel is associated.

[0017] The supervisory software (or in the case of channel reallocation, the host processor) sends a command to the display subsystem to reduce the allocated buffer space of the second thread (or channel) by a certain amount. The display subsystem hardware then implements the reallocation command at a "sync event" for the thread or channel (e.g., at the end of the frame being displayed). Once the reallocation is complete, the display subsystem generates an indication to inform the supervisory software, such as by generating an interrupt or updating a thread size status register accessible by the host processor. Subsequently, the supervisory software issues an allocation command to allocate a certain amount of buffer space to the first thread (or first channel). Again, the display subsystem hardware implements the allocation command at a sync event for the thread or channel.

[0018] Figure 1 A block diagram of a system 100 is depicted according to an example of the present disclosure. The system 100 includes a display subsystem 102, which is coupled to a memory 104, for example, by means of a double data rate (DDR) bus. The display subsystem 102 includes a buffer (e.g., memory) and configurable hardware blocks to implement various functions, which are further explained below. The configurable hardware blocks may include one or more programmable registers that control the functionality of the various hardware blocks. The display subsystem 102 facilitates the interface between the memory 104 and one or more display peripherals 116a to 116d. The display peripherals 116a to 116d include various monitors, remote displays, instrument clusters, and the like.

[0019] The memory 104 contains various display content data, such as graphics content generated by a graphics processing unit (GPU), content captured by one or more cameras, and the like. Regardless of the source of the content, the memory 104 acts as a repository for such content before processing and ultimately displaying it on a display peripheral. As explained above, one example application is in an in-vehicle space, where the display peripherals 116a to 116d include instrument clusters, passenger monitors, and / or rear seat entertainment screens. In this example, the display content data includes instrument data (e.g., a digital speedometer, tachometer, fuel gauge, and other information related to vehicle operation), navigation data, and other entertainment / media data.

[0020] The display subsystem 102 also includes a direct memory access (DMA) engine 106 that fetches display content data from the memory 104. The DMA engine 106 also facilitates writing data (e.g., a fully processed and synthesized display frame of data) back to the memory 104. The DMA engine 106 provides the display content data from the memory 104 to a shared buffer 108. As will be discussed further below, the shared buffer 108 is a local buffer of the display subsystem 102, which ensures that sufficient display content data is available for processing to provide a complete display frame to the display peripherals 116a-116d, which is beneficial for applications in which inline processing (as shown) is utilized to reduce latency (e.g., in-vehicle applications in which one or more of the display peripherals display safety-critical content).

[0021] A plurality of video channels 110a to 110d access display content data stored in a shared buffer 108. Each video channel 110a to 110d corresponds to a window to be displayed on one of the display peripherals 116a to 116d. The video channels 110a to 110d perform processing (e.g., color space conversion, video format conversion, resizing) to generate processed display content data. Each video channel 110a to 110d is configured to provide its processed display content data to a plurality of overlay managers 112a to 112d.

[0022] Overlay managers 112a to 112d perform compositing functions on display content data from one or more of video channels 110a to 110d to create display frames. Figure 1In the example of , overlay manager 112b combines the processed display content data from video channels 110b and 110c and creates a display frame containing the data of those two video channels for display on display peripheral device 116b. For example, one video channel 110b corresponds to an Internet browser application, while another video channel 110c corresponds to ordinary operating system graphics. In this case, overlay manager 112b combines the two display streams into a single display frame. Overlay managers 112a and 112c take processed display content data from video channels 110a and 110d, respectively, and create display frames.

[0023] The display peripherals 116a to 116d are asynchronous in some instances. For example, one display peripheral 116a includes a 60 frames per second (fps) 1080p display, while another display 116b includes a 60fps 4K display, and yet another display peripheral 116c and 116d include 30fps 1080p displays. To address these timing differences, each overlay manager 112a to 112d provides its display frame output to one of the timing generators 114a to 114d, respectively. The timing generators 114a to 114d create an output of the display frame adjusted for its associated display peripheral 116a to 116d. For example, the display peripherals 116a and 116b are 60fps displays, and therefore the timing generators 114a and 114b provide display frames at a rate of 60fps. On the other hand, display peripherals 116c and 116d are 30fps displays, and therefore timing generators 114c and 114d provide display frames at a rate of 30fps. Specifically, in the example, depending on the display rate and resolution, timing generators 114a to 114d slow down data transfers from respective overlay managers 112a to 112d, which in turn slow down data transfers from respective video channels 110a to 110d, which slows down DMA engine 106 accesses.

[0024] In some examples, the display subsystem 102 also includes a write-back pipeline 120 that receives display frame content from the overlay managers 112a to 112d (and in this example, from the video channel 110d). A multiplexer 119 selects which of the overlay managers 112a to 112d and the video channel 110d is provided to the write-back pipeline 120. The write-back pipeline 120 receives input from the multiplexer 119 and facilitates encoding the final output (e.g., the composite display frame from the overlay managers 112a to 112d) and writing the output back to the memory 104 via the shared buffer 108 and the DMA engine 106. For example, some display frames also need to be displayed remotely and are therefore written back to the memory 104 in addition to being sent to one of the display peripherals 116a to 116d for subsequent transmission to the remote display (not shown for brevity). In another example, format conversion is performed via video channel 110 d by extracting the frame to be converted and converting it (e.g., a video frame in memory 104 is in RGB format but needs to be converted to YUV format). The converted frame is then written back to memory 104 from video channel 110 d via write-back pipeline 120. In other examples, multiple of video channels 110 a-110 d are coupled to write-back pipeline 120.

[0025] The system 100 also includes a main processor 150 on which supervisory software 152 (eg, a hypervisor) executes. In an example, one or more host processors 154a-154c are coupled to the main processor 150.

[0026] In an example, the main processor 150 and the host processors 154a to 154c are different, physically separate processors. In this example, the main processor 150 is a safety-critical processor, while the host processors 154a to 154c are general-purpose processors.

[0027] In another example, the main processor 150 and the host processors 154a to 154c are independent processes or virtual machines all running on a single processor. In this example, the main processor 150 is a higher level process (such as a hypervisor or supervisor) and the host processors 154a to 154c are controlled by the main processor 150.

[0028] In yet another example, main processor 150 is a safety critical processor and host processors 154a-154c are virtual machines running on a single general purpose processor.

[0029] Regardless of the configuration, the host processors 154a to 154c generate content for ultimate display on one or more of the display peripherals 116a to 116d, which is stored in the memory 104 for subsequent access by the display subsystem 102. In an example, the host processors 154a to 154c request from the host processor 150 to increase or decrease the size of the shared buffer 108 allocated to the thread or channel associated with the host processors 154a to 154c. In another example, the host processors 154a to c directly cause the increase or decrease in the size of the shared buffer 108 allocated to the channel associated with the host processors 154a to 154c. The host processor 150 and / or the supervisory software 152 executed by the host processor handles such allocation and release requests by communicating with the DMA engine 106, which will be explained in further detail below. The main processor 150 and / or the supervisory software 152 monitor and may override requests by host processors 154a-154c to allocate or release space across channels and threads, e.g., to avoid a deadlock situation in which host processors 154a-154c compete for a particular amount of space. For example, if a host processor 154a requests additional space in the shared buffer 108 for its associated thread, but no other host processors 154b-154c can release their space and there is no free space in the shared buffer 108, the main processor 150 and / or the supervisory software 152 do not implement the request.

[0030] As explained above, the display subsystem 102 operates in an inline manner. That is, except for certain situations where the write-back pipeline 120 is utilized (e.g., for remote display), display content data is read from the memory 104 and displayed on one of the display peripherals 116a to 116d after being processed by the video channels 110a to 110d and synthesized by the overlay managers 112a to 112d explained above. This inline operation results in low latency, which is particularly beneficial in safety-critical applications such as in-vehicle applications; however, the inline operation imposes additional buffering requirements in order to ensure that enough data is available locally to the display subsystem 102 to create a complete display frame at a time.

[0031] Several factors influence the size requirements for the shared buffer 108. For example, the display content data is encoded in the memory 104 at different native resolutions and using different compression schemes, which influences the amount of space in the memory 104 occupied by one row of pixels. Additionally, a particular data fetching pattern or how the DMA engine 106 accesses the display content data from the memory 104 may influence the number of rows of pixel data that will be stored in the shared buffer 108 for a given channel at a given time. Additionally, a particular data consumption pattern or how the video channels 110a-110d consume the display content data from the shared buffer 108 may also influence the number of rows of pixel data that will be stored in the shared buffer 108 for a given channel at a given time.

[0032] For example, using raster fetch mode, one row of pixels is fetched at a time. Therefore, in this case, the space in the shared buffer 108 for a given video channel 110a to 110d should be sufficient to compensate for the round trip delay in accessing the memory 104 and any other system bottlenecks (e.g., system bottlenecks caused by other initiators such as a central processing unit (CPU) or a GPU accessing the memory 104 simultaneously with the display subsystem 102). In an example, one row of storage space in the shared buffer 108 for a given video channel 110a to 110d is sufficient for a particular use case. The buffer size requirements provided herein are exemplary and may be determined on a system-by-system basis so that the buffer does not empty when the fetch rate from the memory 104 is slower (e.g., due to competing accesses from the CPU, GPU, and the like).

[0033] In another example, using a tile extraction mode, pixels are extracted as "tiles", where a tile spans four rows of pixels. In this case, the shared buffer 108 is used in a "reciprocating" mode to access the memory 104. For example, the DMA engine 106 extracts the first group of four rows (as tiles) and stores them in the shared buffer 108, occupying four rows of storage space. The DMA engine 106 then extracts the second group of four rows (as tiles), but it cannot replace the first group of four rows because the first group of four rows are still being processed by the video channels 110a to 110d (e.g., one row at a time). Therefore, the second group of four rows requires an additional four rows of storage space in the shared buffer 108. Once the first group of four rows are completely processed by the video channels 110a to 110d, the DMA engine 106 extracts the third group of four rows, and thus the third group replaces the first group in the shared buffer 108. Therefore, the space in the shared buffer 108 for a given video channel 110a to 110d should be at least enough to store eight complete rows.

[0034] With respect to the consumption mode, using the raster consumption mode, the shared buffer 108 provides one row at a time to a given video channel 110a to 110d. As with the raster extraction mode above, the space in the shared buffer 108 for a given video channel 110a to 110d should be sufficient to compensate for the round trip delay in accessing the memory 104 and any other system bottlenecks, which is typically one row of storage space.

[0035] In another example, using a scalar mode consumption pattern, the shared buffer 108 should be able to send multiple lines in parallel to a given video channel 110a to 110d. For example, if a given video channel 110a to 110d vertically downscales the video by a factor of four, then the shared buffer 108 needs to be able to supply four lines at a time to the given video channel 110a to 110d. Likewise, the shared buffer 108 is used in the "ping-pong" mode as explained above, and therefore requires at least eight lines of storage space.

[0036] Figure 2 A graph 200 is shown showing different shared buffer 108 size requirements in KB for a given channel depending on the display content data original resolution, compression scheme or format, and number of lines (e.g., 1 or 8), which is dictated by the fetch and consume mode as explained above. To illustrate the larger possible differences in shared buffer 108 storage space requirements, the amount of shared buffer 108 space required for a given channel of highly compressed HD raw data using a fetch and consume scheme that requires only 1 line to be stored in the shared buffer 108 at a time is approximately 2.5KB. On the other hand, the amount of shared buffer 108 space required for a given channel of relatively less compressed 4K raw data using a fetch and consume scheme that requires only 8 lines to be stored in the shared buffer 108 at a time is approximately 128KB.

[0037] One possible solution is to allocate a separate buffer of the maximum size that may be required (e.g., 128KB) to each video channel 110a-110d. However, doing so may waste die area because in many cases a particular video channel 110a-110d does not need to be displayed at full 4K resolution, or does not have full 4K resolution data available for it. Additionally, allocating a fixed buffer space to each video channel 110a-110d is inefficient when, for example, one video channel 110a-110d requires increased buffer space based on content and display type while other video channels 110a-110d do not.

[0038] Examples of the present disclosure relate to a shared buffer scheme in which buffer space is dynamically allocated and released on a per-thread and / or per-channel basis. Figure 1And according to examples of the present disclosure, the DMA engine 106 is configured to dynamically allocate memory in the shared buffer 108 to multiple threads, and in some cases to multiple video channels 110a-110d within a thread. As explained above, for purposes of the present disclosure, each overlay manager 112a-112d of the display subsystem 102 constitutes a thread. All video channels 110a-110d that provide processed display content data to a particular overlay manager 112a-112c are part of the same thread and share the memory allocated to the particular thread in the shared buffer 108. Although the video channels 110a-110d are configured to provide processed display content data to any one of the overlay managers 112a-112d, the video channels 110a-110d are configured to provide processed display content data to any one of the overlay managers 112a-112d. Figure 1 In the example of FIG. 1 , the provision of processed display content data is presented by the boxes corresponding to threads 1 to 3. Although Figure 1 Not shown in FIG. 1 but for simplicity, the fourth thread is associated with the overlay manager 112d, but in this example, since no video channels are coupled to the overlay manager 112d, the display peripheral 116d does not display anything.

[0039] exist Figure 1 , thread 1 corresponds to overlay manager 112a and display peripheral 116a, and includes video channel 110a. Thread 1 is shown as being allocated 32KB of shared buffer 108 (represented by the leftmost memory block in shared buffer 108 corresponding to thread 1), with the entire 32KB also being allocated to video channel 110a (represented by the rightmost memory block in shared buffer 108 corresponding to video channel 110a).

[0040] Thread 2 corresponds to overlay manager 112b and display peripheral 116b, and includes video channels 110b and 110c. Thread 2 is shown as being allocated 96KB of shared buffer 108 (represented by the leftmost memory block in shared buffer 108 corresponding to thread 2), with 64KB allocated to video channel 110b and 32KB allocated to video channel 110c (represented by the rightmost memory block in shared buffer 108 corresponding to video channels 110b and 110c).

[0041] Thread 3 corresponds to the overlay manager 112c and the display peripheral 116c, and includes the video channel 110d. Thread 3 is shown as being allocated 32KB of the shared buffer 108 (represented by the leftmost memory block in the shared buffer 108 corresponding to thread 3), with 16KB allocated to the video channel 110d (represented by the rightmost memory block in the shared buffer 108 corresponding to the video channel 110d). As explained above, thread 4 corresponds to the overlay manager 112d and the display peripheral 116d, but is not shown for simplicity. In this example, since no video channels are coupled to the overlay manager 112d, the display peripheral 116d does not display anything.

[0042] Figure 3 A conceptual example 300 of a memory reallocation process implemented by the DMA engine 106 with respect to the shared buffer 108 is shown. The memory reallocation process is now explained in conceptual terms. However, the specific interactions between the DMA engine 106, other display subsystem 102 hardware, the main processor 150, the supervisory software 152, and the host processors 154a to 154c will be explained in further detail below.

[0043] At a first step 302, available memory in the shared buffer 108 is allocated to different threads based on their display resolutions, assuming that the display resolutions are the same in this example. For simplicity, memory units are generally referred to as "blocks," which in practice can be many different sizes. Thus, 4 blocks (an exemplary value) in the shared buffer 108 are allocated to each of threads 1 to 4 immediately after startup. Figure 3 In the example of , for purposes of illustration, assume that thread 4 is allocated space in shared buffer 108, but Figure 1 Thread 4 is omitted from the figure for simplicity.

[0044] It should be noted that different display peripherals 116a to 116d are synchronized at different rates (e.g., the end of a display frame), and therefore the corresponding synchronization events for their associated threads are also different. For simplicity, a thread "synchronizes" refers to the occurrence of a synchronization event when a synchronization event has been successfully displayed for that thread or frame. The DMA engine 106 knows when thread synchronization occurs for each thread, and therefore also only causes the release, allocation, and / or reallocation of memory in the shared buffer 108 immediately after thread synchronization occurs, so as to avoid corruption of the frame being displayed on the associated display peripheral 116a to 116d of a particular thread.

[0045] exist Figure 3In the example 300, it has been determined (e.g., by supervisory software 152 in response to requests from one or more host processors 154a-154c) that thread 1 requires (or could benefit from, if available) 2 additional blocks of shared buffer 108. It has also been determined that thread 3 is able to hand over control of 2 blocks of shared buffer 108. Once a determination has been made that the blocks requested by thread 1 are available from thread 3, the remaining steps of example 300 involve implementing the transaction.

[0046] Prior to step 304, DMA engine 106 has received a command (e.g., from supervisory software 152 in response to a request from one or more host processors 154a-154c) to release 2 blocks from thread 3. Thus, in step 304, DMA engine 106 first releases or deallocates the 2 blocks at the end of memory allocated for thread 3 immediately after synchronization of thread 3. For simplicity, reference is made to "beginning" and "end" or moving blocks "forward" (toward the beginning) or "backward" (toward the end) in memory space, but it should be appreciated that the scheme described herein may also be implemented in reverse.

[0047] At step 306, immediately after thread 4 synchronizes, the DMA engine 106 shifts the memory allocated to thread 4 forward to be adjacent to the memory allocated to thread 3 and creates contiguous free space at the end of the shared buffer 108. Once the memory allocated to threads 1 to 4 in the shared buffer 108 is contiguous, and the free space at the end of the shared buffer 108 is thus fully contiguous, the DMA engine 106 signals the completion of the release operation. For example, the DMA engine 106 generates an indication such as an interrupt supervisor software 152, or an update to a thread status register that can be accessed by the host processor 150 or monitored by the supervisor software 152.

[0048] Once the supervisory software 152 knows that the release has been successfully performed, the allocation of additional space to thread 1 is performed. Thus, in step 308, the DMA engine 106 has received a command (e.g., from the supervisory software 152 in response to a request from one or more host processors 154a to 154c) to allocate 2 additional blocks to thread 1. The DMA engine 106 responds by shifting the memory allocated to the other threads 2 to 4 to create free space adjacent to thread 1. As explained above, this shifting occurs in sequence due to the allocation of space only being performed immediately after thread synchronization to avoid interrupting the display frame. For example, in step 308, immediately after thread 4 synchronizes, the DMA engine 106 shifts the memory allocated to thread 4 back by the required amount to be allocated to thread 1 (2 blocks in this example), which essentially shifts the free space forward from the end of the shared buffer 108.

[0049] Next, in step 310, immediately after thread 3 synchronizes, the DMA engine 106 shifts the memory allocated to thread 3 back by the required amount allocated to thread 1 (2 blocks in this example), which essentially shifts the free space forward from the end of the memory allocated to thread 3.

[0050] Next, in step 312, immediately after Thread 2 synchronizes, the DMA engine 106 shifts the memory allocated to Thread 2 back by the required amount allocated to Thread 1 (2 blocks in this example), which essentially shifts the free space forward from the end of the memory allocated to Thread 2.

[0051] Finally, in step 314, the free space is contiguous with the memory allocated to thread 1. Additionally, if there is any remaining free space, such free space will still be contiguous at the end of the shared buffer 108, since the allocated block is only shifted back by the amount that will be allocated to thread 1. Therefore, the DMA engine 106 allocates the free space to thread 1 immediately after thread 1 synchronizes. As described above, once the memory allocated to threads 1 through 4 in the shared buffer 108 is contiguous, the free space at the end of the shared buffer 108, if any, is sufficiently contiguous, and the DMA engine 106 signals the completion of the allocation operation. As described above, the DMA engine 106 generates, for example, an indication to interrupt the supervisory software 152, or an update to a thread status register that can be accessed by the host processor 150 or monitored by the supervisory software 152.

[0052] The above addresses the inter-thread reallocation process, which in some cases occurs across multiple frames in order to honor thread synchronization event timing and ensure contiguity of allocated space in shared buffer 108. In addition, host processors associated with threads having more than one channel (e.g., host processor 154b and thread 2) cause DMA engine 106 to dynamically reallocate shared buffer 108 space between its channels (e.g., intra-thread reallocation). Host processor 154b directly controls DMA engine 106 to perform intra-thread reallocation in some instances, and performs intra-thread reallocation with the aid of requests to host processor 150 (which then controls DMA engine 106) in other instances.

[0053] As described above, channel "synchronization" refers to the occurrence of synchronization events when the frame for the channel or from the channel has been successfully displayed. However, all channel synchronization events within a given thread occur simultaneously, and it is therefore possible to change the allocation of shared buffer 108 space among the channels within the thread in a single event. In addition, in some instances, the host processor 154b knows the total space in the shared buffer 108 allocated to thread 2, and therefore determines whether redistribution is feasible. The main processor 150 and / or the supervisory software 152 do not need to determine whether another thread 1 or 3 can release the requested space for the channel redistribution within thread 2. In an example, the host processor 154b controls the DMA engine 106 to implement the thread redistribution without involving the main processor 150. In another example, when the host processor 154b requests to change the allocated space between the two channels of thread 2, the main processor 150 and / or the supervisory software causes the DMA engine 106 to redistribute the space between the channels of thread 2 immediately after the occurrence of the channel synchronization event or the thread 2 synchronization event.

[0054] Figure 4 A flow chart of a method 400 is shown illustrating the relationship between the supervisory software 152 and the host processor 150 (under the "software" section) and the display subsystem 102 and (more specifically) the DMA engine 106 (under the "hardware" section) in implementing the above inter-thread and intra-thread reallocation scheme for the shared buffer 108. The method 400 begins in block 402, where a determination is made by the host processor 150 and / or the supervisory software 152 (e.g., in response to a request for release or a request for allocation from a host processor 154a-154c and a determination that another thread is able to release space) to release space in the shared buffer 108 from a thread. This causes the supervisory software 152 to issue a command to the DMA engine 106, for example, to release a specified amount of space from a specified thread.

[0055] The method 400 continues at block 404, where the DMA engine 106 releases the required space from the specified thread upon occurrence of a thread synchronization event for the thread, such as described above with reference to Figure 3 DMA engine 106 updates one or more internal register values ​​and memory pointers (eg, start pointer and end pointer) to reflect the space released from the specified thread.

[0056] In block 406, the DMA engine 106 shifts the allocated space for another thread, consuming the space freed by the release in block 404, and shifting or concatenating any free space at the end of the shared buffer 108. The DMA engine 106 performs the shift immediately after the occurrence of a thread synchronization event for another thread. If more than one thread's allocated space needs to be shifted to consume the space freed by the release in block 404, then block 406 may be repeated, with subsequent shifts occurring separately on synchronization events for those threads.

[0057] Upon completing the shift in box 406 or concatenating the free space at the end of the shared buffer 108, method 400 continues in box 408, where the DMA engine 106 generates an indication, such as an interrupt supervisory software 152, or updates a thread status register that can be accessed by the main processor 150 or monitored by the supervisory software 152 to indicate that the release started in box 404 is complete.

[0058] If the above release request in block 402 is generated in response to a request for allocation from a host processor 154 a to 154 c and a determination that another thread is able to release space, then the method 400 continues in block 410, where the supervisory software 152 issues a command, for example, to the DMA engine 106 to allocate the specified amount of space to the specified thread. If no allocation request is made by the host processor 154 a to 154 c, then the method 400 ends after block 408.

[0059] The method 400 continues at block 412, where the DMA engine 106 shifts the space allocated to another thread to create free space in the shared buffer 108 adjacent to the space allocated to the thread requesting the additional allocated space. As described above, the shifting occurs immediately after the occurrence of the thread synchronization event for the thread that has its allocated space shifted. Additionally, if it is necessary to shift the allocated space of more than one thread to free space adjacent to the thread requesting the additional allocated space, as described above with reference to Figure 3 If steps 308 to 312 are shown and explained, block 412 may be repeated.

[0060] Upon completion of shifting the space allocated to other threads to create free space in the shared buffer 108 adjacent to the space allocated to the thread requesting the additional allocated space, the method 400 continues in block 414, where the DMA engine 106 allocates the adjacent free space to the requesting thread. Upon completion of the allocation in block 414, the method 400 continues in block 416, where the DMA engine 106 generates, for example, an indication to interrupt the supervisory software 152 or updates a thread status register accessible by the host processor 150 or monitored by the supervisory software 152 to indicate that the allocation initiated in block 412 is complete.

[0061] Throughout the method 400, the DMA engine 106 is aware of thread synchronization events for various threads through communication with the timing generators 114a to 114c. The DMA engine 106 also knows which channels are associated with which threads, and therefore can also associate thread synchronization events with the channels of the threads. The allocation, release, and shifting of the allocated space described above all occur on one thread synchronization event or across multiple thread synchronization events, and therefore video data is maintained to be provided to the display peripherals 116a to 116d even during dynamic reallocation among threads or channels within threads. Throughout the method 400, the DMA engine 106 implements the allocation, release, and shifting as described by updating one or more internal register values ​​and memory pointers (e.g., start pointers and end pointers) to reflect changes in the allocated space of each thread.

[0062] Figure 5 A system 500 is shown with additional support for security and privacy features regarding access to various registers that control the configuration of threads and channels in the shared buffer 108, such as thread size, channel size, and the start and / or end point of the allocated space in the shared buffer 108. Figure 5 In, with Figure 1 Elements with the same reference numbers in FIG. 1 operate in the same manner. For the multi-output display subsystem 102 as shown, each display peripheral 116a to 116d is controlled by a different host processor 154a to 154c or main processor 150, and each display peripheral may have a different permission level. In an in-vehicle use case, display peripheral 116a is an instrument cluster display controlled by a safety-critical main processor 150, while display peripheral 116b is a rear seat entertainment display controlled by a general host processor 154b.

[0063] In an example, the shared buffer 108 space allocated to one thread should not be overwritten by another thread, as this could result in a security violation (e.g., overwriting security-critical data sent to the instrument cluster 116a). Additionally, the shared buffer 108 space allocated to one thread should not be read and displayed by another thread, as this could result in a confidentiality violation.

[0064] To prevent security and confidentiality violations, different configuration registers are partitioned so that they are independently firewalled. Various memory mapped register (MMR) areas 502, 504, 506, 508 are coupled to the DMA engine 106. The common MMR area 502 contains thread size registers for all threads (e.g., threads 1 to 4 in this example). Individual MMR areas 504, 506, 508 are associated with each of the channels. Each individual MMR area 504, 506, 508 contains a channel size register. A thread containing multiple channels may be considered to "own" or be able to access and modify all associated channel MMR areas.

[0065] The DMA engine 106 or external control module implements a firewall for both the common MMR area 502 and for each individual MMR area 504, 506, 508. Specifically, only the main processor 150 is allowed to access the common MMR area 502, while other host processors 154a to 154c are blocked from accessing the common MMR area 502. Therefore, inter-thread reallocation requests from the host processors 154a to 154c must be passed through the main processor 150 and its supervisory software 152 in order to implement the reallocation. The host processors 154a to 154c cannot directly request the DMA engine 106 to allocate more memory to its thread, or release memory from another thread, and any such request from the host processors 154a to 154c is rejected.

[0066] Similarly, only the associated host processors 154a to 154c are allowed to access each individual MMR area 504, 506, 508, and the access depends on the association of one or more channels with the threads owned by the host processors 154a to 154c and for the main processor 150. Unassociated host processors 154a to 154c are not allowed to access another individual MMR area 504, 506, 508. For example, the individual MMR area 504 is associated with the host processor 154a. In this example, the host processor 154a and the main processor 150 are allowed to access the individual MMR area 504, while the host processors 154b, 154c are not allowed to access the individual MMR area 504. Therefore, the thread (channel-wise) reallocation request from the associated host processor 154a and the main processor 150 and its supervisory software 152 will be implemented. Other host processors 154b, 154c cannot change the channel assignment of another thread, and any such request from a host processor 154b, 154c is denied in this example.

[0067] In the foregoing discussion and in the claims, the terms "comprise" and "include" are used in an open manner and should therefore be interpreted to mean "including but not limited to...". In addition, the term "couple" means an indirect or direct connection. Thus, if a first device is coupled to a second device, the connection may be by a direct connection, or by an indirect connection via other devices and connections. Similarly, a device coupled between a first component or location and a second component or location may be by a direct connection or by an indirect connection via other devices and connections. An element or feature that is "configured to" perform a task or function may be configured (e.g., programmed or structurally designed) to perform the function when manufactured by a manufacturer, and / or may be configured (or reconfigurable) by a user after manufacturing to perform the function and / or other additional or alternative functions. Configuration may be implemented by firmware and / or software programming of the device, by the construction and / or layout of the hardware components and interconnections of the device, or a combination thereof. Furthermore, the use of the phrase "ground" or similar phrases in the foregoing discussion is intended to include chassis ground, ground line ground, floating ground, virtual ground, digital ground, universal ground, and / or any other form of ground connection that is applicable or suitable for the teachings of the present disclosure. Unless otherwise stated, "about," "approximately," or "substantially" preceding a value means + / - 10% of the stated value.

[0068] The above discussion is intended to illustrate the principles and various embodiments of the present disclosure. Once the above disclosure is fully understood, many changes and modifications will become apparent to those skilled in the art. It is intended that the appended claims be interpreted as encompassing all such changes and modifications.

Claims

1. A system comprising: Direct memory access DMA engine; as well as a buffer coupled to the DMA engine and comprising a storage space allocated to store data received from the DMA engine and to be processed by a thread, the thread comprising a first channel and a second channel to process a first portion of the data and a second portion of the data, respectively, and wherein the storage space comprises a first storage space and a second storage space, the first storage space and the second storage space being allocated to store the first portion of the data for the first channel and the second portion of the data for the second channel, respectively, Wherein the DMA engine is configured as follows: receiving a request for adjusting the size of the first storage space; and In response to the request, adjusting the size of the first storage space; and The second storage space is resized based on the resizing of the first storage space.

2. The system according to claim 1, further comprising: a first processor; as well as A second processor controlled by the first processor. 3 . The system of claim 2 , wherein the DMA engine is configured to receive the request to adjust the size of the first memory space from the first processor. 4 . The system of claim 2 , wherein the DMA engine is configured to receive the request to adjust the size of the first memory space from the second processor.

5. The system of claim 1 , wherein the request indicates a decrease in the size of the first memory space, and wherein the DMA engine is configured to: In response to the request, reducing the size of the first storage space to release a third storage space from the first storage space; adjusting the second storage space to release a fourth storage space from the second storage space, the fourth storage space having the same size as the third storage space; and The remaining portion of the second storage space is linked to the third storage space.

6. The system of claim 1 , wherein the request indicates an increase in the size of the first memory space, and wherein the DMA engine is configured to: In response to the request, determining availability of a third storage space in the second storage space, the third storage space having the same size as the increased size requested for the first storage space; and In response to the availability of the third storage space, reducing the size of the second storage space to release the third storage space from the second storage space; and The first storage space is connected to the third storage space.

7. The system of claim 1, wherein the first portion of the data is generated by a first data source and the second portion of the data is generated by a second data source, and wherein the data is provided from the thread to a display device to be displayed by the display device.

8. A vehicle comprising: monitor; as well as a display subsystem coupled to the display, wherein the display subsystem comprises: Direct memory access DMA engine; as well as a buffer coupled to the DMA engine and comprising a storage space allocated to store data received from the DMA engine and to be processed by a thread, the thread comprising a first channel and a second channel to process a first portion of the data and a second portion of the data, respectively, and wherein the storage space comprises a first storage space and a second storage space, the first storage space and the second storage space being allocated to store the first portion of the data for the first channel and the second portion of the data for the second channel, respectively, Wherein the DMA engine is configured as follows: receiving a request for adjusting the size of the first storage space; and In response to the request, adjusting the size of the first storage space; and The second storage space is resized based on the resizing of the first storage space.

9. The vehicle of claim 8, further comprising: a first processor; as well as A second processor controlled by the first processor. 10 . The vehicle of claim 9 , wherein the DMA engine is configured to receive the request to adjust the size of the first memory space from the first processor. 11 . The vehicle of claim 9 , wherein the DMA engine is configured to receive the request to adjust the size of the first memory space from the second processor.

12. The vehicle of claim 8, wherein the request indicates a decrease in the size of the first memory space, and wherein the DMA engine is configured to: In response to the request, reducing the size of the first storage space to release a third storage space from the first storage space; adjusting the second storage space to release a fourth storage space from the second storage space, the fourth storage space having the same size as the third storage space; and The remaining portion of the second storage space is linked to the third storage space.

13. The vehicle of claim 8, wherein the request indicates an increase in the size of the first memory space, and wherein the DMA engine is configured to: In response to the request, determining availability of a third storage space in the second storage space, the third storage space having the same size as the increased size requested for the first storage space; and In response to the availability of the third storage space, reducing the size of the second storage space to release the third storage space from the second storage space; and The first storage space is connected to the third storage space.

14. A method comprising: providing data from a direct access memory (DMA) engine to a buffer, wherein the buffer includes a memory space allocated to store the data for a thread, the thread including a first channel and a second channel to process a first portion of the data and a second portion of the data, respectively, and wherein the memory space includes a first memory space and a second memory space, the first memory space and the second memory space being allocated to store the first portion of the data and the second portion of the data, respectively; receiving, at the DMA engine, a request to adjust a size of the first memory space allocated to the first channel; as well as In response to the request, the DMA engine, adjusting the size of the first storage space; as well as A size of the second memory space allocated to the second channel is adjusted based on the adjustment of the size of the first memory space.

15. The method according to claim 14, further comprising: generating, by a processor, the request for adjusting the size of the first storage space; as well as The request is provided from the processor to the DMA engine.

16. The method of claim 14, wherein the request indicates an increase in the size of the first storage space, and wherein the method further comprises: In response to the request, the DMA engine, determining availability of a third storage space in the second storage space, the third storage space having the same size as the increased size requested for the first storage space; as well as In response to the availability of the third storage space, reducing the size of the second storage space to release the third storage space from the second storage space; and The first storage space is connected to the third storage space.

17. The method of claim 14, wherein the request indicates a reduction in the size of the first storage space, and wherein the method comprises: In response to the request, the DMA engine, reducing the size of the first storage space to release a third storage space from the first storage space; adjusting the second storage space to release a fourth storage space from the second storage space, the fourth storage space having the same size as the third storage space; as well as The remaining portion of the second storage space is linked to the third storage space.

18. The system of claim 1, wherein before the resizing, the first storage space and the second storage space are adjacent to each other, and wherein the DMA engine is configured to adjust the size of the second storage space based on the adjustment of the size of the first storage space so that the first storage space and the second storage space remain adjacent to each other after the resizing.

19. The system of claim 6, wherein to increase the size of the first memory space, the DMA engine is configured to: After releasing the first storage space from the second storage space, generating a signal indicating that the third storage space has been released; and After the signal is generated, the first storage space and the third storage space are connected.

20. The system of claim 1, further comprising: Main processor; as well as a first host processor and a second host processor, wherein the first host processor and the second host processor are controlled by the main processor, wherein the first host processor and the second host processor are associated with the thread and the second thread, respectively, and wherein the thread generates display content for a first display device and the second thread generates display content for a second display device, Wherein the DMA engine is configured as follows: receiving a second request for adjusting the size of the first storage space or the size of the second storage space; determining that the second request was not provided by the main processor or the first host processor; as well as In response to the determination, the second request is denied.

Images