[PATCH] mx25: set GPT clock source to PER
s.hauer at pengutronix.de
Wed Jul 7 06:28:45 EDT 2010
On Wed, Jul 07, 2010 at 11:00:13AM +0300, Baruch Siach wrote:
> > Tell the timer code which clock to use with an argument to
> > mxc_timer_init() and add the missing clocks to the clock.c file. You
> > also have to pass this argument through from the board to
> > mx25_clocks_init(). That's a lot of work and in the end we still do not
> > know why some i.MX25 variants need the peripheral clock and others need
> > the ipg clock. So what I really suggest is that you invest some
> > research to find the source of this strangeness.
> OK. I think I've nailed it down. The CCM MCR register was initialized
> On the PDK I use the factory installed RedBoot bootloader. RedBoot leaves the
> PER CLK MUX field at its default state, that is, MCR[15:0] = 0.
> On our target board I use a port of Barebox based on the built-in PDK support.
> The board_init_lowlevel routine of the PDK platform code includes the
> following line:
> writel(0x0000FEFF, IMX_CCM_BASE + MX25_CCM_MCR)
> This makes MCR[15:0] = 0xfeff. Commenting out this line makes both boards
> behave the same way. The timer clock runs correctly with or without setting
> the V2_TCTL_CLK_PER bit. Reverting faed406, however, breaks both boards.
> So, I thing we should keep faed406. You may also consider applying this patch
> setting V2_TCTL_CLK_PER, For the reason Rob Herring has stated.
I made some tests on a custom i.MX25 board using barebox (no kernel
CCM_MCR GPT_TCTL[8:6] get_gpt_clk returns result
1. 0xfeff 1 (ipgclk) ipgclk (66.5MHz) works
2. 0x0 1 (ipgclk) ipgclk (66.5MHz) works
3. 0xfeff 2 (perclk) perclk5 (8.87MHz) works
4. 0x0 2 (perclk) perclk5 (16MHz) works
5. 0x0 1 (ipgclk) perclk5 (16MHz) does not work
1 and 2 work because the MCR value only affects perclk, but not ipgclk.
3 and 4 work after I adjusted the per_clk5 divider so that the resulting
clock is < ipgclk / 4. That seems to be what Martin stated.
5 does not work because the timer runs at ipgclk but the clock code
returns per_clk5. This is exactly what the kernel currently does and
it's imho wrong.
reverting faed406 would mean switching to 1 or 2 which should both work.
We may switch to use perclk in the gpt later, but this would require
adjusting the other i.MXs aswell. I'm not convinced this is a good idea
though because currently we have a timer resolution of 1/66.5MHz, we
would go to at least 1/4 of this when using perclk.
I found the following patch in our repository which I forgot to post and
push upstream. Currenty the kernel returns wrong rates for the perclks
when the corresponding CCM_MCR bit is cleared. I hope this patch clears
some confusion instead of adding more...
Author: Sascha Hauer <s.hauer at pengutronix.de>
Date: Mon Sep 14 09:01:13 2009 +0200
mx25 clock: Peripheral parent clock is ahb, not ipg
Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
diff --git a/arch/arm/mach-mx25/clock.c b/arch/arm/mach-mx25/clock.c
index 7d8bca5..cb58b32 100644
@@ -99,7 +99,7 @@ static unsigned long get_rate_per(int per)
if (readl(CRM_BASE + 0x64) & (1 << per))
fref = get_rate_upll();
- fref = get_rate_ipg(NULL);
+ fref = get_rate_ahb(NULL);
return fref / (val + 1);
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the linux-arm-kernel