[PATCH] cpufreq for freescale mx51
From: Yong Shen yong.s...@linaro.org
it is tested on babbage 3.0
Signed-off-by: Yong Shen yong.s...@linaro.org
---
arch/arm/Kconfig |6 +
arch/arm/mach-mx5/Kconfig |1 +
arch/arm/mach-mx5/Makefile |2 +-
arch/arm/mach-mx5/board-mx51_babbage.c |7 +-
arch/arm/mach-mx5/clock-mx51.c | 53 +++
arch/arm/mach-mx5/cpu_wp-mx51.c| 43 ++
arch/arm/plat-mxc/Makefile |2 +
arch/arm/plat-mxc/cpufreq.c| 254
arch/arm/plat-mxc/include/mach/mxc.h | 22 +++-
9 files changed, 387 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-mx5/cpu_wp-mx51.c
create mode 100644 arch/arm/plat-mxc/cpufreq.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4db064e..64ebbc0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1517,6 +1517,12 @@ if ARCH_HAS_CPUFREQ
source drivers/cpufreq/Kconfig
+config CPU_FREQ_IMX
+ tristate CPUfreq driver for i.MX CPUs
+ depends on ARCH_MXC CPU_FREQ
+ help
+ This enables the CPUfreq driver for i.MX CPUs.
+
config CPU_FREQ_SA1100
bool
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 1576d51..5956fee 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -5,6 +5,7 @@ config ARCH_MX51
default y
select MXC_TZIC
select ARCH_MXC_IOMUX_V3
+ select ARCH_HAS_CPUFREQ
comment MX5 platforms:
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index bf23f86..aaa13f8 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -3,7 +3,7 @@
#
# Object file lists.
-obj-y := cpu.o mm.o clock-mx51.o devices.o
+obj-y := cpu.o mm.o clock-mx51.o devices.o cpu_wp-mx51.o
obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c
b/arch/arm/mach-mx5/board-mx51_babbage.c
index ed885f9..038760c 100644
--- a/arch/arm/mach-mx5/board-mx51_babbage.c
+++ b/arch/arm/mach-mx5/board-mx51_babbage.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
* Copyright (C) 2009-2010 Amit Kucheria amit.kuche...@canonical.com
*
* The code contained herein is licensed under the GNU General Public
@@ -43,6 +43,10 @@
#defineMX51_USB_PLL_DIV_19_2_MHZ 0x01
#defineMX51_USB_PLL_DIV_24_MHZ 0x02
+
+extern struct cpu_wp *mx51_get_cpu_wp(int *wp);
+struct cpu_wp *(*get_cpu_wp)(int *wp);
+
static struct platform_device *devices[] __initdata = {
mxc_fec_device,
};
@@ -246,6 +250,7 @@ static void __init mxc_board_init(void)
static void __init mx51_babbage_timer_init(void)
{
+ get_cpu_wp = mx51_get_cpu_wp;
mx51_clocks_init(32768, 2400, 22579200, 0);
}
diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c
index d9f612d..f2488e6 100644
--- a/arch/arm/mach-mx5/clock-mx51.c
+++ b/arch/arm/mach-mx5/clock-mx51.c
@@ -14,6 +14,7 @@
#include linux/delay.h
#include linux/clk.h
#include linux/io.h
+#include linux/time.h
#include asm/clkdev.h
#include asm/div64.h
@@ -28,6 +29,11 @@
static unsigned long external_high_reference, external_low_reference;
static unsigned long oscillator_reference, ckih2_reference;
+extern struct cpu_wp *(*get_cpu_wp)(int *wp);
+static int cpu_wp_nr;
+static int cpu_curr_wp;
+static struct cpu_wp *cpu_wp_tbl;
+
static struct clk osc_clk;
static struct clk pll1_main_clk;
static struct clk pll1_sw_clk;
@@ -38,7 +44,9 @@ static struct clk periph_apm_clk;
static struct clk ahb_clk;
static struct clk ipg_clk;
static struct clk usboh3_clk;
+static void __iomem *pll1_base;
+#define SPIN_DELAY 100 /* in nanoseconds */
#define MAX_DPLL_WAIT_TRIES1000 /* 1000 * udelay(1) = 1ms */
static int _clk_ccgr_enable(struct clk *clk)
@@ -330,6 +338,32 @@ static int _clk_lp_apm_set_parent(struct clk *clk, struct
clk *parent)
return 0;
}
+/*!
+ * Setup cpu clock based on working point.
+ * @param wp cpu freq working point
+ * @return 0 on success or error code on failure.
+ */
+int cpu_clk_set_wp(int wp)
+{
+ struct cpu_wp *p;
+ u32 reg;
+
+ if (wp == cpu_curr_wp)
+ return 0;
+
+ p = cpu_wp_tbl[wp];
+
+ /*use post divider to change freq
+*/
+ reg = __raw_readl(MXC_CCM_CACRR);
+ reg = ~MXC_CCM_CACRR_ARM_PODF_MASK;
+ reg |= cpu_wp_tbl[wp].cpu_podf MXC_CCM_CACRR_ARM_PODF_OFFSET;
+ __raw_writel(reg, MXC_CCM_CACRR);
+ cpu_curr_wp = wp;
+
+ return 0;
+}
+
static unsigned long clk_arm_get_rate(struct clk *clk)
{
u32 cacrr, div;
@@ -342,6 +376,20 @@ static unsigned long clk_arm_get_rate(struct clk *clk)
return parent_rate / div;
}
+int _clk_cpu_set_rate(struct clk *clk, unsigned long rate)
+{
+ u32 i;
+
Maverick packages patched to build with xdeb
Are available from https://launchpad.net/~peter-pearse/+archive/cross-source deb http://ppa.launchpad.net/peter-pearse/cross-source/ubuntu maverick main deb-src http://ppa.launchpad.net/peter-pearse/cross-source/ubuntu maverick main [Any binaries produced will be amd64/i686 proving the host build is unbroken] Only tested to build with gcc-4.5-arm-linux-gnueabi xdeb -a armel --apt-source Resulting armel binaries not tested Please report any problems to me Patches for other packages, reports of other packages which fail to cross-build, etc. welcome... More will be added later, however most packages cross build without patching Regards Peter Pearse ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Maverick packages patched to build with xdeb
Hi Peter, On Tue, Oct 5, 2010 at 2:47 PM, Peter Pearse peter.pea...@linaro.org wrote: [Any binaries produced will be amd64/i686 proving the host build is unbroken] Only tested to build with gcc-4.5-arm-linux-gnueabi xdeb -a armel --apt-source Resulting armel binaries not tested Is there a plan to make those binaries available in some custom repository for wider testing? More will be added later, however most packages cross build without patching Which packages are we trying first? is there a list that you work through somewhere that could be tried by the community help you on this? -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Maverick packages patched to build with xdeb
On Tue, Oct 5, 2010 at 2:04 PM, Alexander Sack a...@linaro.org wrote: Hi Peter, On Tue, Oct 5, 2010 at 2:47 PM, Peter Pearse peter.pea...@linaro.org wrote: [Any binaries produced will be amd64/i686 proving the host build is unbroken] Only tested to build with gcc-4.5-arm-linux-gnueabi xdeb -a armel --apt-source Resulting armel binaries not tested Is there a plan to make those binaries available in some custom repository for wider testing? Negotiations under way to put them on the planned linaro-people server More will be added later, however most packages cross build without patching Which packages are we trying first? is there a list that you work through somewhere that could be tried by the community help you on this? Packages are those for alip-ael as at https://spreadsheets.google.com/a/linaro.org/ccc?key=0AnPR4S1Uev7KdDhHM2RxVGFFY2VQM01MVEJXbTZ3TkEhl=en#gid=0 and https://wiki.ubuntu.com/Specs/M/ARMevaluationAELALIP -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
the linaro toolchain and older arm versions
I believe that the libgcc.a in our toolchain contains Thumb-2 code. I verified this by doing objdump on libgcc.a and I see combinations of 16 and 32 bit instructions. So does that mean that the toolchain is only usable for ARM versions that support Thumb-2? Thanks, John ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: the linaro toolchain and older arm versions
On Wed, Oct 6, 2010 at 11:23 AM, John Rigby john.ri...@linaro.org wrote: Thanks Michael. Just wanted to make sure I understood. The do no harm goal and the Thumb2 libgcc seem to be somewhat contradictory however. I realize that choices need to be made and only odd ducks like me will likely run into issues. I'd like to use our toolchain on my N800 and Cortex-M3 boards as well. The 'do no harm' is at the source level - you should be able to take the Linaro GCC tarball and build a compiler for your particular situation that is as good as and probably more correct than the FSF GCC. Unfortunately we can't make one libgcc that covers all ARM products as some like the Cortex-M series are Thumb-2 only, some like the Cortex-M0 are Thumb-1 only, and some (very old ones) are ARM only. Then you add the floating point options into the mix. It would be nice to ship multiple builds of libgcc with the cross compiler but that's currently out of scope. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: the linaro toolchain and older arm versions
On Tue, Oct 05, 2010 at 04:23:01PM -0600, John Rigby wrote: Thanks Michael. Just wanted to make sure I understood. The do no harm goal and the Thumb2 libgcc seem to be somewhat contradictory however. I realize that choices need to be made and only odd ducks like me will likely run into issues. My particular case is wanting to build u-boot for old and new ARM chips with the same gcc. U-Boot has its own libgcc that I can use as a work around. However, the harm here comes not from any work the Linaro Toolchain WG is doing, it comes from the fact that you're using the Ubuntu toolchain packages, where ARMv7 is targeted as the baseline - and this was the case even before Linaro was off the ground. :) (Even if libgcc were not Thumb2 enabled, you could still have arbitrary, if more subtle, compatibility problems with the Ubuntu armel libgcc and non-ARMv7 chips.) It sounds like what you need for this is a multilib-enabled armel compiler build, that includes a libgcc build for ARMv7 as well as separate libgcc builds for whichever other ARM targets you're after. You should coordinate this with Marcin (cc:ed), who can help with the toolchain packaging details for either a native or cross- compiler. OOI, what are the U-Boot targets you're looking to build for that don't support ARMv7? A gcc multilib package for armel will be easy to implement but hard to maintain, and certainly none of the systems Linaro is targeting should require a pre-Thumb-2 U-Boot, so I'm very doubtful that the ongoing effort to maintain such a toolchain in Ubuntu is justified (unless we find that it becomes substantially easier with multiarch, I guess, but we're a ways away from that yet). Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Patch] Add imx51 support into linaro-media-create
On Thu, Sep 30, 2010 at 5:37 PM, Loïc Minier loic.min...@linaro.org wrote:
+ cat ${TMP_DIR}/boot.cmd BOOTCMD
+setenv bootcmd 'fatload mmc 0:1 0x9000 uImage; fatload mmc 0:1
0x9080 uInitrd; bootm 0x9000 0x9080'
no mmc init?
This is something I'm not very clear. This bootcmd is written into
boot.scr which has to be loaded out from card first, in order to
launch the bootcmd. So we need to get mmc init executed before we
load fatload boot.scr.
Hmm you're right; I was wondering because the other boards at one, but
these boards need to drop it! Fixed
Maybe it's an issue. The u-boot.imx mmc init is not working in this
case. I have to run mmcinfo before the first fatload, or it hangs.
If mmc init breaks in mx51evk u-boot, we should probably fix it; you
could start by filing a bug against u-boot-linaro to track this,
explaining how to trigger the bug.
https://bugs.launchpad.net/u-boot-linaro/+bug/655461
--
Regards,
Shawn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
linaro-media-create speedup
Greets, As a side project I've created a fairly simple performance improvement for the linaro-media-create tool. Basically the copying of the root_fs happens earlier in the process such that hwpack and a number of other steps are done in parallel and then at the end there's one last rsync to make sure adjusted files, further installed files are correctly copied. The code is located here : lp:~tom-gall/linaro-image-tools/rsync-speedup I'm still testing so use with caution. From what I've been able to accomplish thus far, the 67M linaro-headless + hwpack sees the following speed up collected with time: Normal: real10m0.596s user2m2.670s sys 0m9.820s Parallel: real7m58.790s user2m3.170s sys 0m11.950s Feedback gladly accepted, Regards, Tom ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
