topic i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17 in i.MX Processors

i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

controlhorus — Fri, 23 Jan 2015 10:47:43 GMT

Hello

Trying to setup 3.10.17 to use the CCM_CLKO2 to output the 125M clock (01001 on CLKO2_SEL at CCM_CCOSR ) , I found that its name in cko2_sels at clk-imx6q.c is ... "dummy".

What does this mean? Is it not going to work?

I looked the imx6 reference manual for a 125M root clock and I can not found another reference. Is it an errrata? Does that clock not exist?

Thanks and best regards,

Jose

Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

igorpadykov — Mon, 26 Jan 2015 08:55:10 GMT

Hi Diego

this clock is 125 MHz Ref_PCIe generated by Ethernet PLL.

You should see this clock enabling Analog ENET PLL Control

Best regards

igor

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

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

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

Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

controlhorus — Tue, 27 Jan 2015 18:10:36 GMT

Hello

I am trying to test it changing mach-imx6q.c. However the compiled kernel hangs at "Starting kernel".

I am adding lines like this:

u32 reg = (ANADIG_ANA_MISC1_LVDSCLK1_IBEN | ANADIG_ANA_MISC1_LVDS1_CLK_SEL_MASK);

writel(reg, (volatile void __iomem *) 0x20C8168);

Is this kind of writing not allowed at this stage?

Thanks,

Jose

Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

igorpadykov — Wed, 28 Jan 2015 01:25:30 GMT

not sure that I could answer on every fluent code change,

suggest also to post on meta-fsl-arm mailing list

https://lists.yoctoproject.org/listinfo/meta-freescale

~igor

Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

controlhorus — Wed, 28 Jan 2015 09:36:29 GMT

I think it has somenthing to do with iMX6 security system. Access to that registers at that moment seems to be denied and the kernel load crashes.

I am looking for how to change that with no luck. I found that dts configures AIPS registers like this:

aipstz@0207c000

{

reg = <0x207c000 0x4000>;

};

but I changed it to:

aipstz@0207c000

{

reg = <0x207c000 0x77777777>;

};

and I yet have not access to read that same AIPSTZ1 register from mach-imx6q.c

Thanks,

Jose

Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

controlhorus — Wed, 28 Jan 2015 12:34:57 GMT

On mail list, they redirected me to 9.4. Using I/O Memory ... and another mail list :smileyshocked:

It seems that my approach to register access is too 'deprecated' ... and totally wrong .. as i was fearing already. I am going to try to use request_mem_region and ioremap as ehci-fsl.c does

Thanks

Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

igorpadykov — Wed, 28 Jan 2015 14:27:50 GMT

for access memory/register one can look at memtool example

http://repository.timesys.com/buildsources/i/imx-test/imx-test-3.10.17-1.0.0/

~igor

Re: Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

controlhorus — Thu, 29 Jan 2015 11:37:35 GMT

ehci-fsl.c was a bad selection. It is not compiled for imx6.

However, I used the request_mem_region, ioremap and ioread32 process .. and kernel keeps hanging.

Then I traced calls to __request_region on kernel/resource.c. IPU driver is calling this in a different way:

platform_get_resource(pdev, IORESOURCE_MEM, 0);

devm_request_mem_region(&pdev->dev, res->start, resource_size(res), pdev->name);

I am going to email this to the linux-arm list while testing if I can use it.

Thanks,

Jose

Re: Re: i.MX6Q: observation clock cko2 125M_clk_root source configuration on 3.10.17

controlhorus — Thu, 29 Jan 2015 11:40:31 GMT

Hello

memtool uses /dev/mem to access to registers. But I think this is a tool for user space. We have no problems in user space. Our first tests were writing the registers from user space and they worked.

Thanks,

Jose