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

Comments about stability #1468

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

newcokesucks
Copy link

Played around with it and figured this would help others.

Copy link
Contributor

@marcmerlin marcmerlin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Es-tu David Tacher with a brand new github account created just to come here again? :)

@bluelasers
Copy link

It should be noted that this is correct. However there is another way to work through this, but it is much more involved.

The suggested method here works on the idea of max serial clock. Any stalls in the memory bus are problematic. The suggestion here is to use worst case analysis to prove issues. There is another prediction from worst case analysis, which is to intentionally use worst case from memory bus to prove stability. The result of this is a lower serial clock.

The issue with the first worst case analysis is capacity of the cache is critical. The stalls are less problematic and therefore this is faster. However once the cache is too small the memory stalls begin to appear. To works around this you can lower the serial clock which will force compromises in refresh, size and quality. This will still allow for decent sized displays.

There is one small problem with this second worst case analysis approach. That is the refresh rate may spike. However this is solved by configuration using the OE signal timing. If one looks closer they will discover that this is secretly the PWM period which is also the refresh rate.

It should be noted that larger displays are subject to fan out limits, however that is getting off topic. Another slightly off topic point relating to refresh rate is S-PWM which is potentially capable of allow automatic scaling. This is probably only suitable for the second worst case analysis approach. Non-hardware PWM panels generally speaking do not need S-PWM so there is another automatic scaling approach which can be used for both methods without S-PWM. Careful inspection of run time should allow this, but it may be more work than its worth.

My application in theory actually could work with this code base. However I did identify a few issues which would require some structural changes. At this time I am planning to move forward with another approach. Note there are solutions to the memory bus however none are applicable to the Raspberry Pi(s) at this time.

@marcmerlin
Copy link
Contributor

bluelasers Joined GitHub on March 8, 2022. No other code written, no other project, no contributions.
newcokesucks Joined GitHub on September 12, 2022 just in time to fork this project and send a CL. No other code written, no other project, no contributions.
If any of you isn't somehow another account for David Tacher, please write your fork with all your ideas and suggestions, and like Linus would say "show us the code"

@bluelasers
Copy link

I would recommend limiting the number of CPUs given to the OS. Currently three are recommended. Limiting this to one, could provide a path to mitigation.

@marcmerlin
Copy link
Contributor

I recommend assuming bluelasers is still David Tacher and to safely ignore him.

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

Successfully merging this pull request may close these issues.

3 participants