Many displays advertise modes requiring pixel clock frequencies which are impossible to obtain by integer division from the default RK3576 GPLL frequency of 1188 MHz, resulting in a blank screen when the driver settles on a rate which is "close but not quite" what the display expects.
To obtain image on the display in such cases we need to precisely match the display's requested pixel clock within around 0.1% tolerance. Most often this means that we have to change the source PLL frequency for a closer match, and can't use GPLL (which feeds multiple devices across the whole system, and is therefore close to impossible to re-clock without breaking other things).
Current hypothesis is that we should use VPLL instead of GPLL for video outputs by default, and hope that no two displays require weird clocks at the same time (or that they are both the same kind of weird).
Draft implementation here: https://github.com/flipperdevices/flipper-linux-kernel/commits/test-dp/
Many displays advertise modes requiring pixel clock frequencies which are impossible to obtain by integer division from the default RK3576 GPLL frequency of 1188 MHz, resulting in a blank screen when the driver settles on a rate which is "close but not quite" what the display expects.
To obtain image on the display in such cases we need to precisely match the display's requested pixel clock within around 0.1% tolerance. Most often this means that we have to change the source PLL frequency for a closer match, and can't use GPLL (which feeds multiple devices across the whole system, and is therefore close to impossible to re-clock without breaking other things).
Current hypothesis is that we should use VPLL instead of GPLL for video outputs by default, and hope that no two displays require weird clocks at the same time (or that they are both the same kind of weird).
Draft implementation here: https://github.com/flipperdevices/flipper-linux-kernel/commits/test-dp/