Hi,
Our platform defined PLL2 PFD2 as IPU1_DI0 clock source in kernel 4.7-stable for HDMI output. When drm/hdmi driver is requesting for pixel clock 7875000 (in modeline 1024x768@75), it would fail to calculate the desired PFD2 source clock rate and fraction divider value. Is there anyone that could help explain the algorithm in clk_pfd_route_rate function in clk.pdf.c (especially for tmp=tmp*18 + rate/2)?
1. I added some debug messages in NXP clk-pdf.c driver (drivers/clk/imx/clk-pdf.c)
2. The kernel messages show that the desired pixel clock for 1024x768@75 is 7875000 (in the test case - plug only the cable to Dell monitor after booting to linux console)
For some reason, it didn't proceed to run clk_pfd_set_rate, clk_pfd_recalc_rate routines@ in clk-pdf.c
3. HDMI clock source setting in kernel 4.7-stable device tree file
4. The clock use case diagram
Hi,
For 1024x768@75Hz pixel clock issue,
in addition to adding debug messages in clk-pfd.c, I enabled dev_debug mechanism in drivers/gpu/ipu-v3/ipu-di.c.
1. We tried to figure out what you mentioned about clk_pfd_route_rate callback implementation, which could explain why the algorithm drops frac 30 case since the return rate 39375000 is higher than 39375000.
However, if we manually calculate the desired clock rate
(528 * 18 / 31) / 4 = 76.645
With PFD2_FRAC = 31 and 3-bit divider = 4, the calculated clock will be 76.645MHz which is the closest one to the requested. (78.75MHz, 1024X768@75Hz).
We didn't see this case to be checked based on the driver (clk-pdf.c) log messages.
Do you have any suggestions/comments on this ? Any quirks to fix up this issue based on the current clock framework callback implementations?
2. Trying to look into NXP IPU-DI driver - drivers/gpu/ipu-v3/ipu-di.c (checking out branch imx_4.1.15_1.0.0_ga from git://git.freescale.com/imx/linux-2.6-imx.git)
It looks like if the requested pixel clock rate deviation (compared with the rate IPU can give – see line 456-467) is more than 1%, we would have unpredictable/undetermined pixel clock calculation results in defective cases (see line 474-487), where runs NXP clock framework callbacks implementation (e.g. clk-pfd.c).
Could you give me some suggestions/comments on this ?
Thank you
