raisjn
commented
3 years ago from the i.MX reference manual: https://www.nxp.com/docs/en/reference-manual/i.MX_Reference_Manual_Linux.pdf
MXCFB_SET_UPDATE_SCHEME / mxc_epdc_fb_set_upd_scheme Description: Select a scheme that dictates how the flow of updates within the driver. Parameters: __u32 scheme Select of the following updates schemes: UPDATE_SCHEME_SNAPSHOT - In the Snapshot update scheme, the contents of the framebuffer are immediately processed and stored in a driver-internal memory buffer. By the time the call to MXCFB_SEND_UPDATE has completed, the framebuffer region is free and can be modified without affecting the integrity of the last update. If the update frame submission is delayed due to other pending updates, the original buffer contents will be displayed when the update is finally submitted to the EPDC hardware. If the update results in a collision, the original update contents will be resubmitted when the collision has cleared. UPDATE_SCHEME_QUEUE - The Queue update scheme uses a work queue to asynchronously handle the processing and submission of all updates. When an update is submitted via MXCFB_SEND_UPDATE, the update is added to the queue and then processed in order as EPDC hardware resources become available. As a result, the framebuffer contents processed and updated are not guaranteed to reflect what was present in the framebuffer when the update was sent to the driver. UPDATE_SCHEME_QUEUE_AND_MERGE - The Queue and Merge scheme uses the queueing concept from the Queue scheme, but adds a merging step. This means that, before an update is processed in the work queue, it is first compared with other pending updates. If any update matches the mode and flags of the current update and also overlaps the update region of the current update, then that update will be merged with the current update. After attempting to merge all pending updates, the final merged update will be processed and submitted.
currently, rm2fb runs its updates in a loop and its possible for a series of large updates to clog the SWTCON up. for example, if 10 full screen updates are placed in the queue, it would likely cause 1+ second of delay.
we've previously explored putting large updates into a separate thread, but that led to strange issues and had to be undone.
this task is to enable update merging. for example: let's say there are X items in the queue after a large update. instead of running each item individually, we can merge the remaining updates for each waveform mode and consolidate their dirty rectangles.
there are many ways of handling merging, so part of this task is to also research what merge styles existed in mxcfb, as well as to understand what merging is built in to SWTCON.