Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

merge outstanding updates after a slow update #42

Open
raisjn opened this issue Jan 31, 2021 · 1 comment
Open

merge outstanding updates after a slow update #42

raisjn opened this issue Jan 31, 2021 · 1 comment

Comments

@raisjn
Copy link
Collaborator

raisjn commented Jan 31, 2021

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.

@raisjn
Copy link
Collaborator Author

raisjn commented Jan 31, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant