Is there a register to turn the display clock? Just fine turn.
Not quite sure about what fine tune you want to do.
Please check if tuning guide has anything you want.
Hello, it seems that there is no such a register set the pixel clock.
Pixel clock is decided by the EDID/mode read from your monitor. There is no register to “tune” it.
As you said pixel clock is from EDID, that means the resolution can be defined by myself when I modify the EDID, that means pixel clock can be defined. I think there is a register to redefine the clock or PLL.
I would suggest you directly modify the EDID. Or just trace the driver code by yourself…
Your random modification to the register may just ruin the driver behavior…
Can you show me how to trace the driver code. I can find
cat /sys/kernel/debug/clk/nvdisplay_disp/clk_rate 594000000(maybe to be 594000000±100K), I just want to turn this clock, but I can not find the setting place.
Display driver is starting from the probe function in dc.c. You could start from that first.
There should be a nominal clock calculation log printed in dmesg… you could use that to trace the code…
I don’t know if you know what you are doing here.
Modifying the clock from /sys/kernel/debug is not the right way… The software driver programs the registers already. If some clocks are not enabled on your side, it means that clock is not in use by display driver…
Is there any Information about clocks. It seems that NV doesn’t reference the settings for the clock registers.
Could you elaborate what do you want to do exactly? or what problem do you hit?
Current situation is you just came up and said “I want enable this clock, or that clock” but I totally don’t know why you need to enable or tune a clock.
As I said already, the driver already handled the clock well. You shouldn’t directly modify the clock from register. What you want to do will just break the driver’s behavior.
To be more precise, if you think this is NVIDIA driver bug, please help clarify your problem or point out what goes wrong in our driver.
Ha,I know. Driver has no bugs.
i’m using drm on my project and I just need to decode H.265 stream and display as quickly as I can. But there is a phase difference between the decoder and the display, that means sometimes I can’t display when the decoder has decoded a frame immediately. I have solved it by fine tuning the pixel clock in other SOC. So I need to know how to set the pixel clock register.
Could you elaborate what is “phase difference” here?
In ideal state, I need the decoder decode a frame and display immediately. Similarly, the following picture.
But in fact, when the time goes on, pixel phase difference will change, because the temperature and Deviation of oscillator. That will cause the display is slower 1 frame than the source. So I will fine tune the phase to make the display is right to the decoder capture to promise the display as faster as I can.
I just need to fine tune the pixel clock. This method is tested and verified on the other soc.
This method may not work on jetson. We only guarantee the display can match pixel clock provided from display EDID.
If you are talking about there would be a delay between source and display side, then please tell us how to reproduce your issue and we would check.
BTW, I know the problem you are talking about. We have handled such problem before but the solution may not be “fine tune pixel clock”. It is more related to the swap buffer timing does not match between display and decocder so your frame get handled in later cycle of display refresh.
HaHa, you can appreciate like this and how to solve it if I don’t fine tune pixel clock.
Must promise that the decode and display immediately.
Basically you could use ftrace to check the the timing between your application sent a frame to display and when the display driver calls scanout function.
If your application cannot send a buffer in a stable speed to catch the vsync/scanout of display, then it will definitely wait for next vsync.
You don’t understand what I said. The reason of Phase shift is difference in components and temperature…
If you don’t fine tune the pixel clock, the phenomenon will be like that, 1 minute is picture 1 and the next minute is picture 2. It will cross happen.
The request is similar to G-Sync. Since we don’t support it on Jetson platforms, so it may not work in this way. Please note this.