Fix panic in scanvideo.c with recurring sys_clk #61
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the system clock is set to a value which is a recurring number, scanvideo.c will always panic even when the system clock is effectively an integer multiple of 2 times the desired pixel clock.
This is due to the system clock and the pixel clock being truncated to different levels of precision. e.g:
I was experimenting with custom scanvideo timings and wanted an output using a 14.318181Mhz pixel clock (or a close approximation of this NTSC frequency) and vcocalc.py gave the following solution for an 8x system clock:
Requested: 114.545448 MHz
Achieved: 114.66666666666667 MHz
FBDIV: 86 (VCO = 1032 MHz)
PD1: 3
PD2: 3
I set the system clock with the above values and specified the pixel clock frequency as 14333333 in my scanvideo timing struct (timing->clock_freq) and that led to the panic:
System clock (114666666) must be an integer multiple of 2 times the requested pixel clock (14333333).
This is due to the way the comparison is made by multiplying the pixel clock by the scale factor and comparing with the system clock which will fail as 14333333*8 = 114666664 not 114666666.
The fix is to divide the system clock by the scale factor and compare with the pixel clock and this will succeed as both sides have been truncated to the same level of precision. (114666666 / 8 = 14333333)