iMx6 linux clk driver question - clk-pfd.c

[kenlin]

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

[igorpadykov]

Hi Ken

please use official nxp bsps on i.MX6 product page

i.MX 6 Series Software and Development Tool|NXP

as answered by bsp experts on

kobs-ng with 4.4+ kernels on imx6 processors

NXP does not support kernel mainline. Only our BSP versions are guarantee to work.

For 4.7 kernel issues one can post on kernel.org mail list

Best regards

igor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[kenlin]

Hi,

I found the same clk-pdf.c(arch/arm/mach-imx/clk-pdf.c) used in iMx6 BSP (git branch imx_4.1.15_1.0.0_ga from git://git.freescale.com/imx/linux-2.6-imx.git), which is supposed to be supported by NXP. 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)?

Thank you

[igorpadykov · Accepted solution]

Hi

please look at description of CCM_ANALOG_PFD.. in

sect.18.7.16 i.MX6DQ Reference Manual

http://cache.freescale.com/files/32bit/doc/ref_manual/IMX6DQRM.pdf

and EB790_Configuring PFD

http://cache.nxp.com/files/32bit/doc/eng_bulletin/EB790.pdf

Regarding clk_pfd_route_rate algorithms please refer to documentation of

common linux clock frame work, like struct clk_ops,

clk_pfd_round_rate/.round_rate described in general linux documentation

https://www.kernel.org/doc/Documentation/clk.txt

or for example "Common clock framework" presentation

http://elinux.org/images/b/b8/Elc2013_Clement.pdf

Best regards

igor

[kenlin]

Hi,

Thank you for the document info.

My question is about the clk framework callback implementation (clk_pfd_route_rate function) in  NXP clk-pfd driver (clk-pfd.c).

Is there anyone that could help explain the algorithm in clk_pfd_route_rate function in clk.pfd.c (especially for tmp=tmp*18 + rate/2)?

[igorpadykov]

this is used for rounding up the divider so that one don't set a rate

higher than what is requested :

#define ROUND_DIV(a, b) ((2 * (a) + b) / (2 * (b)))

                div = ROUND_DIV((LONGLONG)refFreq * 18, freq);

                div = (div < 12) ? 12 : div;

                div = (div > 35) ? 35 : div;

               ..

[kenlin]

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

[igorpadykov]

Suggest to elevate your question using local fae channel
so somebody from bsp team could comment on that. I have not
contacts with bsp team.

Best regards
igor

[kenlin]

Hi,

The local FAE would suggest directing this question to the NXP community forum.

Cheers,

ken Lin

[igorpadykov]

Personally I believe that choosing one optimization algorithm over another

is matter of developer. If necessary to achieve better accuracy,

one can develop own algorithm.

Best regards
igor