All of lore.kernel.org
 help / color / mirror / Atom feed
From: s.hauer@pengutronix.de (Sascha Hauer)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mx25: set GPT clock source to PER
Date: Wed, 7 Jul 2010 12:28:45 +0200	[thread overview]
Message-ID: <20100707102845.GW26079@pengutronix.de> (raw)
In-Reply-To: <20100707080012.GE24774@jasper.tkos.co.il>

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 
> differently.  
> 
> 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
started)

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...

commit 98901d5f62de56d87d3a31e46ebe9624edeac62b
Author: Sascha Hauer <s.hauer@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@pengutronix.de>

diff --git a/arch/arm/mach-mx25/clock.c b/arch/arm/mach-mx25/clock.c
index 7d8bca5..cb58b32 100644
--- a/arch/arm/mach-mx25/clock.c
+++ b/arch/arm/mach-mx25/clock.c
@@ -99,7 +99,7 @@ static unsigned long get_rate_per(int per)
 	if (readl(CRM_BASE + 0x64) & (1 << per))
 		fref = get_rate_upll();
 	else
-		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 |

  reply	other threads:[~2010-07-07 10:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-21 15:00 [PATCH 0/2] mx25: clock related fixes Baruch Siach
2010-01-21 15:00 ` [PATCH 1/2] mx25: remove unused mx25_clocks_init() argument Baruch Siach
2010-01-21 15:00 ` [PATCH 2/2] mx25: properly initialize clocks, fix time accounting Baruch Siach
2010-01-22  6:50   ` Baruch Siach
2010-01-22  7:57   ` Sascha Hauer
2010-01-25 10:54     ` Baruch Siach
2010-01-25 10:58       ` [PATCH 1/4] mx25: remove unused mx25_clocks_init() argument Baruch Siach
2010-01-25 10:58       ` [PATCH 2/4] mx25: properly initialize clocks Baruch Siach
2010-07-05  7:08         ` Uwe Kleine-König
2010-07-08 10:04           ` Baruch Siach
2010-01-25 10:58       ` [PATCH 3/4] mx25: fix time accounting Baruch Siach
2010-01-25 11:11         ` Lothar Waßmann
2010-01-25 15:01           ` Baruch Siach
2010-05-11 15:43         ` Sascha Hauer
2010-05-12  5:06           ` Baruch Siach
2010-05-12  9:46             ` Sascha Hauer
2010-05-12 10:45               ` Baruch Siach
2010-05-12 12:09                 ` Sascha Hauer
2010-07-06 15:28                 ` Rob Herring
2010-07-04  8:43               ` Baruch Siach
2010-07-04  8:47                 ` [PATCH] mx25: set GPT clock source to PER Baruch Siach
2010-07-05  8:21                   ` Sascha Hauer
2010-07-06  6:35                     ` Baruch Siach
2010-07-06  7:33                       ` Sascha Hauer
2010-07-06 14:06                         ` Rob Herring
2010-07-07  8:00                         ` Baruch Siach
2010-07-07 10:28                           ` Sascha Hauer [this message]
2010-07-07 13:04                             ` Baruch Siach
2010-07-05 11:18                 ` [PATCH 3/4] mx25: fix time accounting Martin Fuzzey
2010-01-25 10:58       ` [PATCH 4/4] mx25: make the FEC AHB clk secondary of the IPG Baruch Siach
2010-01-22  7:58   ` [PATCH 2/2] mx25: properly initialize clocks, fix time accounting Sascha Hauer
2010-01-22  7:59   ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100707102845.GW26079@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.