Re: CMA vs HIGHMEM issue
On 12/20/2011 03:38 PM, Somebody in the thread at some point said: Hi - Is it expected CMA and high memory should work OK? I see there's a note in the CMA log about "implement support for contiguous memory areas placed in HIGHMEM zone", but it's ambiguous if it should be ignoring highmem or is expected to blow chunks. If it's expected to blow chunks, is there a hack or workaround that will allow us to have both HIGHMEM and CMA on OMAP4? I'm aware of this issue, I hope to post a fix ASAP I finish some of my urgent bug fixing related to our project. In meantime I suggest using 2G/2G memory split as a workaround (Kernel Features -> Memory split -> 2G/2G user/kernel split). Thanks a lot for the helpful reply Marek. I made a workaround hack earlier using CONFIG_ZONE_DMA to restrict it to the non-Himem area for DMA. http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=patch;h=f8dcdd9914e97f9b4293d9cf4f397e5af17b66e0 but your suggestion is more elegant. I'm unsure of the ramifications of the 2G / 2G scheme so I'll give it a try later. CMA is looking like it's going to be very cool... the camera driver wanted a 10MB allocation and before CMA patches, it looked intractably stuck with 2MB max... afterwards, no problemo. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: CMA vs HIGHMEM issue
Hello Andy, On Tuesday, December 20, 2011 2:56 AM You wrote: > I recently brought in v 15 (and then v 17) of the CMA patches on > tilt-tracking and backported to tilt-3.1 in order to support Panda > onboard camera. > > Without any highmem, stuff is working great, but with HIGHMEM, inclusion > of either v15 and v17 CMA consistently blows chunks during DMA init like > this --> > > [0.517761] Enabling ERRATA 751472 > [0.521392] OMAP4: Map 0xafe0 to 0xfe60 for dram barrier > [0.529510] print_constraints: dummy: > [0.534973] NET: Registered protocol family 16 > [0.550659] Unable to handle kernel NULL pointer dereference at > virtual address > [0.559082] pgd = c0004000 > [0.561950] [] *pgd= > [0.565734] Internal error: Oops: 805 [#1] PREEMPT SMP > [0.571136] Modules linked in: > [0.574371] CPU: 0Tainted: GW(3.1.0-panda_tilt-3.1+ #2) > [0.581268] PC is at __memzero+0x24/0x80 > [0.585388] LR is at 0x0 > [0.588073] pc : []lr : [<>]psr: 2013 > [0.588104] sp : ef833f54 ip : fp : > [0.600067] r10: c0838c80 r9 : r8 : > [0.605560] r7 : ef833f84 r6 : c14ac000 r5 : 0004 r4 : > [0.612335] r3 : r2 : r1 : 0003ffc0 r0 : > [0.619140] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM > Segment kernel > [0.626770] Control: 10c5387f Table: 8000404a DAC: 0015 > [0.632751] Process swapper (pid: 1, stack limit = 0xef8322f8) > [0.638854] Stack: (0xef833f54 to 0xef834000) > [0.643432] 3f40: > c001df04 c0d3c000 0004 > [0.651947] 3f60: 0647 c001dfa4 c08910a4 0004 045f > c0838cc0 > [0.660461] 3f80: c08710cc c08ed640 ef832000 > c0008900 009f c009e3c8 > [0.668975] 3fa0: 009f c0838c80 c00145ec 00393531 > c014 c08abcf4 > [0.677459] 3fc0: 019a c08710cc c087186c c00145ec 0013 > > [0.685974] 3fe0: c0834874 c08347e8 > c00145ec 37a42f33 10139e95 > [0.694488] Code: e52de004 e1a0c002 e1a0e002 e2511040 (a8a0500c) > [0.700866] ---[ end trace 1b75b31a2719ed1d ]--- > [0.705749] Kernel panic - not syncing: Attempted to kill init! > [0.711944] CPU1: stopping > [0.714843] [] (unwind_backtrace+0x0/0xf8) from > [] (do_IPI+0xf0/0x118) > [0.723449] [] (do_IPI+0xf0/0x118) from [] > (__irq_svc+0x34/0xd0) > [0.731506] Exception stack(0xef873f90 to 0xef873fd8) > [0.736785] 3f80: ffed > 00ce3000 ef873fd8 > [0.745300] 3fa0: ef872000 c08ed704 c05e2a8c c0890754 c0890914 > 411fc092 > [0.753814] 3fc0: 0001 ef873fd8 c0014648 c001464c 6113 > [0.760742] [] (__irq_svc+0x34/0xd0) from [] > (default_idle+0x24/0x28) > [0.769256] [] (default_idle+0x24/0x28) from [] > (cpu_idle+0xfc/0x11c) > [0.70] [] (cpu_idle+0xfc/0x11c) from [<805d1954>] > (0x805d1954) > > Is it expected CMA and high memory should work OK? I see there's a note > in the CMA log about "implement support for contiguous memory areas > placed in HIGHMEM zone", but it's ambiguous if it should be ignoring > highmem or is expected to blow chunks. > > If it's expected to blow chunks, is there a hack or workaround that will > allow us to have both HIGHMEM and CMA on OMAP4? I'm aware of this issue, I hope to post a fix ASAP I finish some of my urgent bug fixing related to our project. In meantime I suggest using 2G/2G memory split as a workaround (Kernel Features -> Memory split -> 2G/2G user/kernel split). Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 4/7] cpufreq: add generic cpufreq driver
On Mon, Dec 19, 2011 at 09:00:44AM -0600, Rob Herring wrote: > On 12/19/2011 08:39 AM, Jamie Iles wrote: > > On Mon, Dec 19, 2011 at 10:19:29PM +0800, Richard Zhao wrote: > >> On Mon, Dec 19, 2011 at 10:05:12AM +, Jamie Iles wrote: > >>> Hi Richard, > >>> > >>> On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote: > It support single core and multi-core ARM SoCs. But currently it assume > all cores share the same frequency and voltage. > > Signed-off-by: Richard Zhao > --- > .../devicetree/bindings/cpufreq/generic-cpufreq|7 + > drivers/cpufreq/Kconfig|8 + > drivers/cpufreq/Makefile |2 + > drivers/cpufreq/generic-cpufreq.c | 251 > > 4 files changed, 268 insertions(+), 0 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/cpufreq/generic-cpufreq > create mode 100644 drivers/cpufreq/generic-cpufreq.c > > diff --git a/Documentation/devicetree/bindings/cpufreq/generic-cpufreq > b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq > new file mode 100644 > index 000..15dd780 > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq > @@ -0,0 +1,7 @@ > +Generic cpufreq driver > + > +Required properties in /cpus/cpu@0: > +- compatible : "generic-cpufreq" > >>> > >>> I'm not convinced this is the best way to do this. By requiring a > >>> generic-cpufreq compatible string we're encoding Linux driver > >>> information into the hardware description. The only way I can see to > >>> avoid this is to provide a generic_clk_cpufreq_init() function that > >>> platforms can call in their machine init code to use the driver. > > Agreed on the compatible string. Assume you reject to use compatible string. > It's putting Linux specifics into DT. > > You could flip this around and have the module make a call into the > kernel to determine whether to initialize or not. Then platforms could > set a flag to indicate this. Could you make it more clear? kernel global variable, macro, or function? - Following your idea, I think, we can add in driver/cpufreq/cpufreq.c: int (*clk_reg_cpufreq_get_op_table) (struct op_table *tbl, int *size); SoC code set the callback. If it's NULL, driver will exit. We can get rid of DT. It'll make cpufreq core dirty, but it's the only file built-in. - Drop module support. SoC call generic_clk_cpufreq_init as Jamie said. > > >> It'll prevent the driver from being a kernel module. > > > > Hmm, that's not very nice either! I guess you _could_ add an > > of_machine_is_compatible() check against a list of compatible machines > > in the driver but that feels a little gross. Hopefully Rob or Grant > > have a good alternative! > > > > What does cpufreq core do if multiple drivers are registered? current cpufreq core only support one cpufreq_driver. Others will fail except the first time. > Perhaps a > ranking is needed and this would only get enabled if there are no other > drivers and other conditions like having the clock "cpu" present are met. We'd better keep cpufreq core simple. For this driver, register cpufreq_driver is the last thing after checking all conditions. > > Rob > > >> Hi Grant & Rob, > >> > >> Could you comment? > >> > >>> > +- cpu-freqs : cpu frequency points it support > +- cpu-volts : cpu voltages required by the frequency point at the same > index > +- trans-latency : transition_latency > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index e24a2a1..216eecd 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -179,6 +179,14 @@ config CPU_FREQ_GOV_CONSERVATIVE > > If in doubt, say N. > > +config GENERIC_CPUFREQ_DRIVER > +bool "Generic cpufreq driver using clock/regulator/devicetree" > +help > + This adds generic CPUFreq driver. It assumes all > + cores of the CPU share the same clock and voltage. > + > + If in doubt, say N. > >>> > >>> I think this needs dependencies on HAVE_CLK, OF and REGULATOR. > >> right, Thanks. I can not check clk before generic clock framework > >> come in. > >> Added: > >>depends on OF && REGULATOR > >>select CPU_FREQ_TABLE > > > > You can still use HAVE_CLK. That symbol has been around for ages and > > any platform implementing the clk API should select it so it's fine to > > depend on it even before there is a generic struct clk. You are right. Thanks. Richard > > > > Jamie > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ___ linaro-dev mailing
CMA vs HIGHMEM issue
Hi - I recently brought in v 15 (and then v 17) of the CMA patches on tilt-tracking and backported to tilt-3.1 in order to support Panda onboard camera. Without any highmem, stuff is working great, but with HIGHMEM, inclusion of either v15 and v17 CMA consistently blows chunks during DMA init like this --> [0.517761] Enabling ERRATA 751472 [0.521392] OMAP4: Map 0xafe0 to 0xfe60 for dram barrier [0.529510] print_constraints: dummy: [0.534973] NET: Registered protocol family 16 [0.550659] Unable to handle kernel NULL pointer dereference at virtual address [0.559082] pgd = c0004000 [0.561950] [] *pgd= [0.565734] Internal error: Oops: 805 [#1] PREEMPT SMP [0.571136] Modules linked in: [0.574371] CPU: 0Tainted: GW(3.1.0-panda_tilt-3.1+ #2) [0.581268] PC is at __memzero+0x24/0x80 [0.585388] LR is at 0x0 [0.588073] pc : []lr : [<>]psr: 2013 [0.588104] sp : ef833f54 ip : fp : [0.600067] r10: c0838c80 r9 : r8 : [0.605560] r7 : ef833f84 r6 : c14ac000 r5 : 0004 r4 : [0.612335] r3 : r2 : r1 : 0003ffc0 r0 : [0.619140] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [0.626770] Control: 10c5387f Table: 8000404a DAC: 0015 [0.632751] Process swapper (pid: 1, stack limit = 0xef8322f8) [0.638854] Stack: (0xef833f54 to 0xef834000) [0.643432] 3f40: c001df04 c0d3c000 0004 [0.651947] 3f60: 0647 c001dfa4 c08910a4 0004 045f c0838cc0 [0.660461] 3f80: c08710cc c08ed640 ef832000 c0008900 009f c009e3c8 [0.668975] 3fa0: 009f c0838c80 c00145ec 00393531 c014 c08abcf4 [0.677459] 3fc0: 019a c08710cc c087186c c00145ec 0013 [0.685974] 3fe0: c0834874 c08347e8 c00145ec 37a42f33 10139e95 [0.694488] Code: e52de004 e1a0c002 e1a0e002 e2511040 (a8a0500c) [0.700866] ---[ end trace 1b75b31a2719ed1d ]--- [0.705749] Kernel panic - not syncing: Attempted to kill init! [0.711944] CPU1: stopping [0.714843] [] (unwind_backtrace+0x0/0xf8) from [] (do_IPI+0xf0/0x118) [0.723449] [] (do_IPI+0xf0/0x118) from [] (__irq_svc+0x34/0xd0) [0.731506] Exception stack(0xef873f90 to 0xef873fd8) [0.736785] 3f80: ffed 00ce3000 ef873fd8 [0.745300] 3fa0: ef872000 c08ed704 c05e2a8c c0890754 c0890914 411fc092 [0.753814] 3fc0: 0001 ef873fd8 c0014648 c001464c 6113 [0.760742] [] (__irq_svc+0x34/0xd0) from [] (default_idle+0x24/0x28) [0.769256] [] (default_idle+0x24/0x28) from [] (cpu_idle+0xfc/0x11c) [0.70] [] (cpu_idle+0xfc/0x11c) from [<805d1954>] (0x805d1954) Is it expected CMA and high memory should work OK? I see there's a note in the CMA log about "implement support for contiguous memory areas placed in HIGHMEM zone", but it's ambiguous if it should be ignoring highmem or is expected to blow chunks. If it's expected to blow chunks, is there a hack or workaround that will allow us to have both HIGHMEM and CMA on OMAP4? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/3] regulator: twl: adapt twl-regulator driver to dt
On Tue, Dec 13, 2011 at 03:49:33PM +0530, Rajendra Nayak wrote: I'm OK with this but would prefer that OMAP or TWL people were OK with it too. If you do need to respin: > +For twl4030 regulators/LDO's ' should *not* be used for plurals except when omitting a duplicated s introduced by one (grammar nit but it really bugs me). ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Writing to the ACTLR register on Cortex a9
Hi, I am trying to modify the ACTLR register. But it is not possible because Linux kernel is booting in non-secure mode. For the same reason I cannot fix some errata by writing to the diagnostic register. I am using Snowball board. A very simple question I have: Is it possible to call secure monitor (SMC command) to perform simple writings to the registers? Or somehow boot Linux in secure mode? Thanks ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[patch] reduce namespace polloution from sys/ucontext.h on arm
On arm linux sys/ucontext.h heavilly polloutes the global
namespace firstly by including sys/user.h (which defines
among other things a type called "struct user" and secondly
by defining symbols and #defines named R? to represent
the processor registers.
That issue in itself is nothing new but fairly recently*
signal.h started including sys/ucontext.h by default
causing programs that (quite reasonable IMO) used those
names for their own symbols to fail to build on arm. This
has been especially noticable recently because debian is
trying to build the new "armhf" port.
After discussions on debian-arm/debian-glibc/linaro-dev
(I do not know which responders came from which list)
I was given the following advice on the "struct user"
issue by Ulrich Weigand.
>Now, glibc also provides a file that defines
>layouts of register sets for use with signal handlers as well
>as the makecontext/setcontext/getcontext family of routines.
>
>Usually, those layouts tend to be in fact identical to the
>layouts described in / . Apparently,
>whoever implemented the ARM version of was
>trying to avoid some seemingly unnecessary code duplication
>by making *include* and using
>the information from there directly. This is not done on other
>platforms, for precisely the reason that the
>and headers do pollute the name space ...
>
>So I think the right thing to do in the short term would be to
>stop including , and instead add the
>register set information there directly, even if that means some
>duplication of code. (Again, since this is never-changing ABI,
>duplication isn't actually all that bad. Also, all the other
>platforms do it that way too, so why should ARM be different ...)
On the issue of the R? definitions I proposed renaming them
to REG_R?. The use of a REG_ prefix is consistent with
x86, x64 and sparc (I couldn't find any comparable definitions
at all on other architectures I looked at) I asked what the
impact of this change would be on the aforementioned mailing
lists and got the following reply from Konstantinos Margaritis
>at worst the packages that had to be workaround on arm* for this, can
>have the workaround removed.
The attached patch implements these changes.
My tests do not show any new failures in the libc testsuite (though
I do get failures that debian considers "unexpected" regardless
of whether this patch is applied or not)
* I have not investigated exactly when this change occoured
but it was somewhere between the version in debian squeeze
and the version in debian wheezy.
Index: eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h
===
--- eglibc-2.13.orig/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2006-08-17 01:23:58.0 +
+++ eglibc-2.13/ports/sysdeps/unix/sysv/linux/arm/sys/ucontext.h 2011-12-17 12:52:43.0 +
@@ -23,7 +23,6 @@
#include
#include
-#include
/* We need the signal context definitions even if they are not used
included in . */
@@ -35,47 +34,64 @@
#define NGREG 18
/* Container for all general registers. */
-typedef elf_gregset_t gregset_t;
+typedef greg_t gregset_t[NGREG];
/* Number of each register is the `gregset_t' array. */
enum
{
- R0 = 0,
-#define R0 R0
- R1 = 1,
-#define R1 R1
- R2 = 2,
-#define R2 R2
- R3 = 3,
-#define R3 R3
- R4 = 4,
-#define R4 R4
- R5 = 5,
-#define R5 R5
- R6 = 6,
-#define R6 R6
- R7 = 7,
-#define R7 R7
- R8 = 8,
-#define R8 R8
- R9 = 9,
-#define R9 R9
- R10 = 10,
-#define R10 R10
- R11 = 11,
-#define R11 R11
- R12 = 12,
-#define R12 R12
- R13 = 13,
-#define R13 R13
- R14 = 14,
-#define R14 R14
- R15 = 15
-#define R15 R15
+ REG_R0 = 0,
+#define REG_R0 REG_R0
+ REG_R1 = 1,
+#define REG_R1 REG_R1
+ REG_R2 = 2,
+#define REG_R2 REG_R2
+ REG_R3 = 3,
+#define REG_R3 REG_R3
+ REG_R4 = 4,
+#define REG_R4 REG_R4
+ REG_R5 = 5,
+#define REG_R5 REG_R5
+ REG_R6 = 6,
+#define REG_R6 REG_R6
+ REG_R7 = 7,
+#define REG_R7 REG_R7
+ REG_R8 = 8,
+#define REG_R8 REG_R8
+ REG_R9 = 9,
+#define REG_R9 REG_R9
+ REG_R10 = 10,
+#define REG_R10 REG_R10
+ REG_R11 = 11,
+#define REG_R11 REG_R11
+ REG_R12 = 12,
+#define REG_R12 REG_R12
+ REG_R13 = 13,
+#define REG_R13 REG_R13
+ REG_R14 = 14,
+#define REG_R14 REG_R14
+ REG_R15 = 15
+#define REG_R15 REG_R15
};
+struct _libc_fpstate
+{
+ struct
+ {
+unsigned int sign1:1;
+unsigned int unused:15;
+unsigned int sign2:1;
+unsigned int exponent:14;
+unsigned int j:1;
+unsigned int mantissa1:31;
+unsigned int mantissa0:32;
+ } fpregs[8];
+ unsigned int fpsr:32;
+ unsigned int fpcr:32;
+ unsigned char ftype[8];
+ unsigned int init_flag;
+};
/* Structure to describe FPU registers. */
-typedef elf_fpregset_t fpregset_t;
+typedef struct _libc_fpstate fpregset_t;
/* Context to describe whole processor state. This only describes
the core registers; coprocessor registers get saved elsewhere
_
Re: [PATCH V3 4/7] cpufreq: add generic cpufreq driver
Hi Richard,
On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote:
> It support single core and multi-core ARM SoCs. But currently it assume
> all cores share the same frequency and voltage.
>
> Signed-off-by: Richard Zhao
> ---
> .../devicetree/bindings/cpufreq/generic-cpufreq|7 +
> drivers/cpufreq/Kconfig|8 +
> drivers/cpufreq/Makefile |2 +
> drivers/cpufreq/generic-cpufreq.c | 251
>
> 4 files changed, 268 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> create mode 100644 drivers/cpufreq/generic-cpufreq.c
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> new file mode 100644
> index 000..15dd780
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> @@ -0,0 +1,7 @@
> +Generic cpufreq driver
> +
> +Required properties in /cpus/cpu@0:
> +- compatible : "generic-cpufreq"
I'm not convinced this is the best way to do this. By requiring a
generic-cpufreq compatible string we're encoding Linux driver
information into the hardware description. The only way I can see to
avoid this is to provide a generic_clk_cpufreq_init() function that
platforms can call in their machine init code to use the driver.
> +- cpu-freqs : cpu frequency points it support
> +- cpu-volts : cpu voltages required by the frequency point at the same index
> +- trans-latency : transition_latency
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index e24a2a1..216eecd 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -179,6 +179,14 @@ config CPU_FREQ_GOV_CONSERVATIVE
>
> If in doubt, say N.
>
> +config GENERIC_CPUFREQ_DRIVER
> + bool "Generic cpufreq driver using clock/regulator/devicetree"
> + help
> + This adds generic CPUFreq driver. It assumes all
> + cores of the CPU share the same clock and voltage.
> +
> + If in doubt, say N.
I think this needs dependencies on HAVE_CLK, OF and REGULATOR.
> +
> menu "x86 CPU frequency scaling drivers"
> depends on X86
> source "drivers/cpufreq/Kconfig.x86"
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index ce75fcb..2dbdab1 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -13,6 +13,8 @@ obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) +=
> cpufreq_conservative.o
> # CPUfreq cross-arch helpers
> obj-$(CONFIG_CPU_FREQ_TABLE) += freq_table.o
>
> +obj-$(CONFIG_GENERIC_CPUFREQ_DRIVER) += generic-cpufreq.o
> +
>
> ##
> # x86 drivers.
> # Link order matters. K8 is preferred to ACPI because of firmware bugs in
> early
> diff --git a/drivers/cpufreq/generic-cpufreq.c
> b/drivers/cpufreq/generic-cpufreq.c
> new file mode 100644
> index 000..781bb9b
> --- /dev/null
> +++ b/drivers/cpufreq/generic-cpufreq.c
> @@ -0,0 +1,251 @@
> +/*
> + * Copyright (C) 2011 Freescale Semiconductor, Inc.
> + */
> +
> +/*
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static u32 *cpu_freqs; /* HZ */
> +static u32 *cpu_volts; /* uV */
> +static u32 trans_latency; /* ns */
> +static int cpu_op_nr;
> +
> +static struct clk *cpu_clk;
> +static struct regulator *cpu_reg;
> +static struct cpufreq_frequency_table *freq_table;
> +
> +static int set_cpu_freq(unsigned long freq, int index, int higher)
> +{
> + int ret = 0;
> +
> + if (higher && cpu_reg)
> + regulator_set_voltage(cpu_reg,
> + cpu_volts[index], cpu_volts[index]);
> +
> + ret = clk_set_rate(cpu_clk, freq);
> + if (ret != 0) {
> + pr_err("generic-cpufreq: cannot set CPU clock rate\n");
> + return ret;
> + }
> +
> + if (!higher && cpu_reg)
> + regulator_set_voltage(cpu_reg,
> + cpu_volts[index], cpu_volts[index]);
> +
> + return ret;
> +}
> +
> +static int generic_verify_speed(struct cpufreq_policy *policy)
> +{
> + return cpufreq_frequency_table_verify(policy, freq_table);
> +}
> +
> +static unsigned int generic_get_speed(unsigned int cpu)
> +{
> + return clk_get_rate(cpu_clk) / 1000;
> +}
> +
> +static int generic_set_target(struct cpufreq_policy *policy,
> + unsigned int target_freq, unsigned int relation)
> +{
> + struct cpufreq_freqs freqs;
> + unsigned long freq_Hz;
> + int cpu;
> + int ret = 0;
Re: [PATCH V3 4/7] cpufreq: add generic cpufreq driver
On Mon, Dec 19, 2011 at 10:19:29PM +0800, Richard Zhao wrote: > On Mon, Dec 19, 2011 at 10:05:12AM +, Jamie Iles wrote: > > Hi Richard, > > > > On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote: > > > It support single core and multi-core ARM SoCs. But currently it assume > > > all cores share the same frequency and voltage. > > > > > > Signed-off-by: Richard Zhao > > > --- > > > .../devicetree/bindings/cpufreq/generic-cpufreq|7 + > > > drivers/cpufreq/Kconfig|8 + > > > drivers/cpufreq/Makefile |2 + > > > drivers/cpufreq/generic-cpufreq.c | 251 > > > > > > 4 files changed, 268 insertions(+), 0 deletions(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/cpufreq/generic-cpufreq > > > create mode 100644 drivers/cpufreq/generic-cpufreq.c > > > > > > diff --git a/Documentation/devicetree/bindings/cpufreq/generic-cpufreq > > > b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq > > > new file mode 100644 > > > index 000..15dd780 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq > > > @@ -0,0 +1,7 @@ > > > +Generic cpufreq driver > > > + > > > +Required properties in /cpus/cpu@0: > > > +- compatible : "generic-cpufreq" > > > > I'm not convinced this is the best way to do this. By requiring a > > generic-cpufreq compatible string we're encoding Linux driver > > information into the hardware description. The only way I can see to > > avoid this is to provide a generic_clk_cpufreq_init() function that > > platforms can call in their machine init code to use the driver. > It'll prevent the driver from being a kernel module. Hmm, that's not very nice either! I guess you _could_ add an of_machine_is_compatible() check against a list of compatible machines in the driver but that feels a little gross. Hopefully Rob or Grant have a good alternative! > Hi Grant & Rob, > > Could you comment? > > > > > > +- cpu-freqs : cpu frequency points it support > > > +- cpu-volts : cpu voltages required by the frequency point at the same > > > index > > > +- trans-latency : transition_latency > > > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > > > index e24a2a1..216eecd 100644 > > > --- a/drivers/cpufreq/Kconfig > > > +++ b/drivers/cpufreq/Kconfig > > > @@ -179,6 +179,14 @@ config CPU_FREQ_GOV_CONSERVATIVE > > > > > > If in doubt, say N. > > > > > > +config GENERIC_CPUFREQ_DRIVER > > > + bool "Generic cpufreq driver using clock/regulator/devicetree" > > > + help > > > + This adds generic CPUFreq driver. It assumes all > > > + cores of the CPU share the same clock and voltage. > > > + > > > + If in doubt, say N. > > > > I think this needs dependencies on HAVE_CLK, OF and REGULATOR. > right, Thanks. I can not check clk before generic clock framework > come in. > Added: > depends on OF && REGULATOR > select CPU_FREQ_TABLE You can still use HAVE_CLK. That symbol has been around for ages and any platform implementing the clk API should select it so it's fine to depend on it even before there is a generic struct clk. Jamie ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 1/4] cpufreq: add arm soc generic cpufreq driver
On 12/18/11 17:03, Richard Zhao wrote: > > Do you have to patch to implement per-cpu udelay? In current code, udelay uses > global loops_per_jiffy. > > We've been carrying forward the timer based udelay patches. They're in the patch tracker as 6873/1, 6874/1, and 6875/1. -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 01/06] MFD: DA9052/53 MFD core module v10
Hi Mark, On Tue, Dec 13, 2011 at 02:33:45PM +0800, Mark Brown wrote: > On Mon, Dec 12, 2011 at 08:06:56PM +0530, Ashish Jangam wrote: > > The DA9052/53 is a highly integrated PMIC subsystem with supply domain > > flexibility to support wide range of high performance application. > > > It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery > > control and other functionality. > > > This patch is functionally tested on Samsung SMDKV6410. > > Reviewed-by: Mark Brown > > Looking good now! Samuel, this uses regmap-irq so either I can carry > this or you can merge: The former is fine with me, thanks in advance. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Weird, weird Linux on ARM, a LinuxCon presentation
On 1 December 2011 13:01, Christian Robottom Reis wrote: > I did a presentation this November at LinuxCon Brazil called "The > Wierd World of Linux on ARM (featuring Android)": > > https://events.linuxfoundation.org/events/linuxcon-brasil/programacao > > I thought the slides might be interesting, so I posted them here: > > https://wiki.linaro.org/ChristianReis > > Linus didn't ask me any questions, so your comments are even more > welcome than usual. Thanks! I think that's a real good presentation. I especially like the "how fortunate are we to have problems like this" bent. Another point to make under the other OS's section is to note that Linux on ARM is by far the most successful embedded development platform because Linux can be hacked on so easily. Still another point to bring up is that binary blob based development is killing productivity for ARM SoC manufactures and their customers since each new "drop" must be integrated, tested, etc... Also mentioning that because of this, device manufactures cannot realistically track a tip kernel, because the binary blobs either have to be regenerated or reintegrated. This is made even more difficult because these blobs are typically generated in remote locations apart from the core code base. Etc... > -- > Christian Robottom Reis, Engineering VP > Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 > Linaro.org: Open Source Software for ARM SoCs > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [patch] reduce namespace polloution from sys/ucontext.h on arm
On Mon, 19 Dec 2011, peter green wrote: > On the issue of the R? definitions I proposed renaming them > to REG_R?. The use of a REG_ prefix is consistent with > x86, x64 and sparc (I couldn't find any comparable definitions > at all on other architectures I looked at) I asked what the > impact of this change would be on the aforementioned mailing > lists and got the following reply from Konstantinos Margaritis > > >at worst the packages that had to be workaround on arm* for this, can > >have the workaround removed. The most obvious users of these definitions would be (native) GDB and gdbserver - do those still build OK (i.e. include the correct headers to get the definitions they need and not rely on any definitions that were removed) after this patch? Have you verified that it still works to include both and in the same source file, in either order? -- Joseph S. Myers jos...@codesourcery.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Initial Linaro+Android kernel for 11.12 is available
I think bero's workaround that Michael Hope suggested, pass -mno-unaligned-access to the kernel via KFLAGS may fix this. The change we made on Android was: http://review.android.git.linaro.org/#patch,sidebyside,1285,1,tasks/kernel.mk On 7 December 2011 23:05, john stultz wrote: > Zach reminded me that this month is compressed, so a linaro+android > kernel would be needed immediately for 11.12. As Andrey is just ramping > up in taking over for the Linaro Android kernel maintenance, I wanted to > just get a kernel out, using the older kernel workflow, so that we had > something current for 11.12. > > Anyway. This is straight from Andy Green's > linaro-androidization-tracking branch, with a few small build fixes > added on that I found in my testing and the base android_*_defconfig > files. > > You can find the tree here: > git://android.git.linaro.org/kernel/linaro-android.git > linaro-android-3.2-agreen-rebase > > The current sha is tagged as: linux-linaro-3.2-2011.12-0-android-0 > > Known issues: > There seems to be something in the androidization branch that is causing > problems on beagle xm and origen. In my testing beagle xm kernel ends up > hanging in mid-boot(after ~4 seconds). And the orgien board doesn't > show anything past "Uncompressing Linux... done, booting the kernel". If > I drop the androidization patches and go back to the v3.2-rc4 base, both > kernels boot until the Android userland environment starts and falls > over because the android features are missing. I mucked about for awhile > on both of these tonight, but wasn't able to solve either of them, so > I'd appreciate any help trying to narrow down what is wrong on Origen > (beagle is apparently lower priority). > > Andy, one issue with the re-factored android patch tree: Its not very > bisect-able. If I jump back to a topic branch, frequently there are > missing dependencies that keep it from building. Any thoughts on how we > can better chase down these sorts of issues? > > thanks > -john > > > > -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 4/7] cpufreq: add generic cpufreq driver
On 12/19/2011 08:39 AM, Jamie Iles wrote: > On Mon, Dec 19, 2011 at 10:19:29PM +0800, Richard Zhao wrote: >> On Mon, Dec 19, 2011 at 10:05:12AM +, Jamie Iles wrote: >>> Hi Richard, >>> >>> On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote: It support single core and multi-core ARM SoCs. But currently it assume all cores share the same frequency and voltage. Signed-off-by: Richard Zhao --- .../devicetree/bindings/cpufreq/generic-cpufreq|7 + drivers/cpufreq/Kconfig|8 + drivers/cpufreq/Makefile |2 + drivers/cpufreq/generic-cpufreq.c | 251 4 files changed, 268 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/cpufreq/generic-cpufreq create mode 100644 drivers/cpufreq/generic-cpufreq.c diff --git a/Documentation/devicetree/bindings/cpufreq/generic-cpufreq b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq new file mode 100644 index 000..15dd780 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq @@ -0,0 +1,7 @@ +Generic cpufreq driver + +Required properties in /cpus/cpu@0: +- compatible : "generic-cpufreq" >>> >>> I'm not convinced this is the best way to do this. By requiring a >>> generic-cpufreq compatible string we're encoding Linux driver >>> information into the hardware description. The only way I can see to >>> avoid this is to provide a generic_clk_cpufreq_init() function that >>> platforms can call in their machine init code to use the driver. Agreed on the compatible string. It's putting Linux specifics into DT. You could flip this around and have the module make a call into the kernel to determine whether to initialize or not. Then platforms could set a flag to indicate this. >> It'll prevent the driver from being a kernel module. > > Hmm, that's not very nice either! I guess you _could_ add an > of_machine_is_compatible() check against a list of compatible machines > in the driver but that feels a little gross. Hopefully Rob or Grant > have a good alternative! > What does cpufreq core do if multiple drivers are registered? Perhaps a ranking is needed and this would only get enabled if there are no other drivers and other conditions like having the clock "cpu" present are met. Rob >> Hi Grant & Rob, >> >> Could you comment? >> >>> +- cpu-freqs : cpu frequency points it support +- cpu-volts : cpu voltages required by the frequency point at the same index +- trans-latency : transition_latency diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index e24a2a1..216eecd 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -179,6 +179,14 @@ config CPU_FREQ_GOV_CONSERVATIVE If in doubt, say N. +config GENERIC_CPUFREQ_DRIVER + bool "Generic cpufreq driver using clock/regulator/devicetree" + help +This adds generic CPUFreq driver. It assumes all +cores of the CPU share the same clock and voltage. + +If in doubt, say N. >>> >>> I think this needs dependencies on HAVE_CLK, OF and REGULATOR. >> right, Thanks. I can not check clk before generic clock framework >> come in. >> Added: >> depends on OF && REGULATOR >> select CPU_FREQ_TABLE > > You can still use HAVE_CLK. That symbol has been around for ages and > any platform implementing the clk API should select it so it's fine to > depend on it even before there is a generic struct clk. > > Jamie ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V3 4/7] cpufreq: add generic cpufreq driver
On Mon, Dec 19, 2011 at 10:05:12AM +, Jamie Iles wrote:
> Hi Richard,
>
> On Mon, Dec 19, 2011 at 11:21:40AM +0800, Richard Zhao wrote:
> > It support single core and multi-core ARM SoCs. But currently it assume
> > all cores share the same frequency and voltage.
> >
> > Signed-off-by: Richard Zhao
> > ---
> > .../devicetree/bindings/cpufreq/generic-cpufreq|7 +
> > drivers/cpufreq/Kconfig|8 +
> > drivers/cpufreq/Makefile |2 +
> > drivers/cpufreq/generic-cpufreq.c | 251
> >
> > 4 files changed, 268 insertions(+), 0 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> > create mode 100644 drivers/cpufreq/generic-cpufreq.c
> >
> > diff --git a/Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> > b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> > new file mode 100644
> > index 000..15dd780
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/cpufreq/generic-cpufreq
> > @@ -0,0 +1,7 @@
> > +Generic cpufreq driver
> > +
> > +Required properties in /cpus/cpu@0:
> > +- compatible : "generic-cpufreq"
>
> I'm not convinced this is the best way to do this. By requiring a
> generic-cpufreq compatible string we're encoding Linux driver
> information into the hardware description. The only way I can see to
> avoid this is to provide a generic_clk_cpufreq_init() function that
> platforms can call in their machine init code to use the driver.
It'll prevent the driver from being a kernel module.
Hi Grant & Rob,
Could you comment?
>
> > +- cpu-freqs : cpu frequency points it support
> > +- cpu-volts : cpu voltages required by the frequency point at the same
> > index
> > +- trans-latency : transition_latency
> > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> > index e24a2a1..216eecd 100644
> > --- a/drivers/cpufreq/Kconfig
> > +++ b/drivers/cpufreq/Kconfig
> > @@ -179,6 +179,14 @@ config CPU_FREQ_GOV_CONSERVATIVE
> >
> > If in doubt, say N.
> >
> > +config GENERIC_CPUFREQ_DRIVER
> > + bool "Generic cpufreq driver using clock/regulator/devicetree"
> > + help
> > + This adds generic CPUFreq driver. It assumes all
> > + cores of the CPU share the same clock and voltage.
> > +
> > + If in doubt, say N.
>
> I think this needs dependencies on HAVE_CLK, OF and REGULATOR.
right, Thanks. I can not check clk before generic clock framework
come in.
Added:
depends on OF && REGULATOR
select CPU_FREQ_TABLE
>
> > +
> > menu "x86 CPU frequency scaling drivers"
> > depends on X86
> > source "drivers/cpufreq/Kconfig.x86"
> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> > index ce75fcb..2dbdab1 100644
> > --- a/drivers/cpufreq/Makefile
> > +++ b/drivers/cpufreq/Makefile
> > @@ -13,6 +13,8 @@ obj-$(CONFIG_CPU_FREQ_GOV_CONSERVATIVE) +=
> > cpufreq_conservative.o
> > # CPUfreq cross-arch helpers
> > obj-$(CONFIG_CPU_FREQ_TABLE) += freq_table.o
> >
> > +obj-$(CONFIG_GENERIC_CPUFREQ_DRIVER) += generic-cpufreq.o
> > +
> >
> > ##
> > # x86 drivers.
> > # Link order matters. K8 is preferred to ACPI because of firmware bugs in
> > early
> > diff --git a/drivers/cpufreq/generic-cpufreq.c
> > b/drivers/cpufreq/generic-cpufreq.c
> > new file mode 100644
> > index 000..781bb9b
> > --- /dev/null
> > +++ b/drivers/cpufreq/generic-cpufreq.c
> > @@ -0,0 +1,251 @@
> > +/*
> > + * Copyright (C) 2011 Freescale Semiconductor, Inc.
> > + */
> > +
> > +/*
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static u32 *cpu_freqs; /* HZ */
> > +static u32 *cpu_volts; /* uV */
> > +static u32 trans_latency; /* ns */
> > +static int cpu_op_nr;
> > +
> > +static struct clk *cpu_clk;
> > +static struct regulator *cpu_reg;
> > +static struct cpufreq_frequency_table *freq_table;
> > +
> > +static int set_cpu_freq(unsigned long freq, int index, int higher)
> > +{
> > + int ret = 0;
> > +
> > + if (higher && cpu_reg)
> > + regulator_set_voltage(cpu_reg,
> > + cpu_volts[index], cpu_volts[index]);
> > +
> > + ret = clk_set_rate(cpu_clk, freq);
> > + if (ret != 0) {
> > + pr_err("generic-cpufreq: cannot set CPU clock rate\n");
> > + return ret;
> > + }
> > +
> > + if (!higher && cpu_reg)
> > + regulator_set_voltage(cpu_reg,
> > + cpu_volts[index], cpu_volts[index]);
> >
Re: [PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Hi Wolfgsng Denk, On 19 December 2011 14:33, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message <1324285004-32354-2-git-send-email-chander.kash...@linaro.org> > you wrote: > > Add TCMPB3 field in pwm structure, earliar this was res1. > > > > Signed-off-by: Chander Kashyap > > --- > > arch/arm/include/asm/arch-exynos/pwm.h |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/arch/arm/include/asm/arch-exynos/pwm.h > b/arch/arm/include/asm/arch-exynos/pwm.h > > index d0cf3cb..3e95160 100644 > > You submit a V2 patch, but without any indication what was changed ??? > Changes are in Patch2/2. I have mentioned them in Patch2/2. > > Where is the _mandatory_ change log? > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Always try to do things in chronological order; it's less confusing > that way. > -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Wolfgang Denk, On 19 December 2011 14:29, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message < > canuqghhq_+az6z100agouaumeuyxwh-hl6anpgrtowbadeq...@mail.gmail.com> you > wrote: > > > > > In message < > 1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > > > you wrote: > > > > Earliar ARM clock frequency was calculated by: > > > > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > > > > It is fixed by calcuating it as follows: > > > > > > Um Comment and code disagree: > > > > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > > > > > ...or is this just missing a paren? > > > > > > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > > > + dout_apll /= (core2_ratio + 1); > > > > > > This gives > > > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > > > > > Please check if this is correct. > > > > > > > Below is the scenario of selection. > > > > MOUTAPLL --->| MUX_CORE |>MOUTCORE > > MOUTMPLL --->|| > > > > Here MOUTAPLL is selected as input. So Parent is correct. > > You miss the point. > > Your comment: > >ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > is missing one opening brace. Depending on where you insert it, the > code may or may not match. > Thanks, I got it. Resend it again. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "A little knowledge is a dangerous thing."- Doug Gwyn > -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Dear Chander Kashyap, In message <1324285004-32354-2-git-send-email-chander.kash...@linaro.org> you wrote: > Add TCMPB3 field in pwm structure, earliar this was res1. > > Signed-off-by: Chander Kashyap > --- > arch/arm/include/asm/arch-exynos/pwm.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/include/asm/arch-exynos/pwm.h > b/arch/arm/include/asm/arch-exynos/pwm.h > index d0cf3cb..3e95160 100644 You submit a V2 patch, but without any indication what was changed ??? Where is the _mandatory_ change log? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always try to do things in chronological order; it's less confusing that way. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Chander Kashyap, In message you wrote: > > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > > you wrote: > > > Earliar ARM clock frequency was calculated by: > > > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > > > It is fixed by calcuating it as follows: > > > > Um Comment and code disagree: > > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > > > ...or is this just missing a paren? > > > > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > > + dout_apll /= (core2_ratio + 1); > > > > This gives > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > > > Please check if this is correct. > > > > Below is the scenario of selection. > > MOUTAPLL --->| MUX_CORE |>MOUTCORE > MOUTMPLL --->|| > > Here MOUTAPLL is selected as input. So Parent is correct. You miss the point. Your comment: ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) is missing one opening brace. Depending on where you insert it, the code may or may not match. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "A little knowledge is a dangerous thing."- Doug Gwyn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: power measurements on snowball
CC'ing Snowball User mailing list. On 16/12/11 10:51, Amit Kucheria wrote: > Great! Thanks David. I've linked to it and Vincent's page from here: > > https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/BoardHackingforPower > > On Fri, Dec 16, 2011 at 2:39 AM, David Anders wrote: >> Amit, >> >> i've started a wiki page with some of the basic information: >> >> http://elinux.org/PandaBoard_Power_Measurements >> >> Dave >> >> >> On 12/15/2011 08:40 AM, Amit Kucheria wrote: >>> >>> On Thu, Dec 15, 2011 at 2:06 PM, Vincent Guittot >>> wrote: >>> Hi, I have added a wiki page which described how to modify your snowball to do more precise power measurements https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Power_snowball >>> >>> Very cool Vincent. Now I hope we get something similar for the >>> Pandaboard from David. *nudge* :) >>> >>> /Amit >>> >> >> > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- Lee Jones Linaro ST-Ericsson Landing Team Lead M: +44 77 88 633 515 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 0/2] Exynos Related fixes
Chander Kashyap (2): Exynos: PWM: Add TCMPB3 field in pwm structure Exynos: Fix ARM Clock frequency calculation arch/arm/cpu/armv7/exynos/clock.c | 15 +-- arch/arm/include/asm/arch-exynos/pwm.h |2 +- 2 files changed, 10 insertions(+), 7 deletions(-) -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Add TCMPB3 field in pwm structure, earliar this was res1.
Signed-off-by: Chander Kashyap
---
arch/arm/include/asm/arch-exynos/pwm.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/pwm.h
b/arch/arm/include/asm/arch-exynos/pwm.h
index d0cf3cb..3e95160 100644
--- a/arch/arm/include/asm/arch-exynos/pwm.h
+++ b/arch/arm/include/asm/arch-exynos/pwm.h
@@ -57,7 +57,7 @@ struct s5p_timer {
unsigned inttcmpb2;
unsigned inttcnto2;
unsigned inttcntb3;
- unsigned intres1;
+ unsigned inttcmpb3;
unsigned inttcnto3;
unsigned inttcntb4;
unsigned inttcnto4;
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 2/2] Exynos: Fix ARM Clock frequency calculation
Earliar ARM clock frequency was calculated by: MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. It is fixed by calculating it as follows: ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) Signed-off-by: Chander Kashyap --- Changes for V2: - Fixed commit comment - Fixed comment in clock.c "exynos4_get_arm_clk ()" - Renamed dout_apll to armclk in clock.c "exynos4_get_arm_clk ()" arch/arm/cpu/armv7/exynos/clock.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv7/exynos/clock.c b/arch/arm/cpu/armv7/exynos/clock.c index 64de262..0c199cd 100644 --- a/arch/arm/cpu/armv7/exynos/clock.c +++ b/arch/arm/cpu/armv7/exynos/clock.c @@ -102,17 +102,20 @@ static unsigned long exynos4_get_arm_clk(void) struct exynos4_clock *clk = (struct exynos4_clock *)samsung_get_base_clock(); unsigned long div; - unsigned long dout_apll; - unsigned int apll_ratio; + unsigned long armclk; + unsigned int core_ratio; + unsigned int core2_ratio; div = readl(&clk->div_cpu0); - /* APLL_RATIO: [26:24] */ - apll_ratio = (div >> 24) & 0x7; + /* CORE_RATIO: [2:0], CORE2_RATIO: [30:28] */ + core_ratio = (div >> 0) & 0x7; + core2_ratio = (div >> 28) & 0x7; - dout_apll = get_pll_clk(APLL) / (apll_ratio + 1); + armclk = get_pll_clk(APLL) / (core_ratio + 1); + armclk /= (core2_ratio + 1); - return dout_apll; + return armclk; } /* exynos4: return pwm clock frequency */ -- 1.7.5.4 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
On 19 December 2011 13:56, Minkyu Kang wrote: > On 19 December 2011 16:57, Wolfgang Denk wrote: > > Dear Chander Kashyap, > > > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > you wrote: > >> Earliar ARM clock frequency was calculated by: > >> MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > >> It is fixed by calcuating it as follows: > > > > Um Comment and code disagree: > > > >> ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > > > ...or is this just missing a paren? > > > >> + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > >> + dout_apll /= (core2_ratio + 1); > > > > This gives > > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > > > Please check if this is correct. > > Wolfgang, you are right. > ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) is right. > I will fix the comment. > > > Dear Chander Kashyap, > > >/* APLL_RATIO: [26:24] */ > > Please fix this comment also. > Yes > > > - apll_ratio = (div >> 24) & 0x7; > > + core_ratio = (div >> 0) & 0x7; > > + core2_ratio = (div >> 28) & 0x7; > > > > - dout_apll = get_pll_clk(APLL) / (apll_ratio + 1); > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > This output is not dout_apll. > Please fix it. > I will rename the output. > > > + dout_apll /= (core2_ratio + 1); > > > >return dout_apll; > > Thanks > Minkyu Kang > -- > from. prom. > www.promsoft.net > -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Wolfgang Denk, On 19 December 2011 13:50, Chander Kashyap wrote: > Dear Wolfgang Denk, > > > On 19 December 2011 13:27, Wolfgang Denk wrote: > >> Dear Chander Kashyap, >> >> In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> >> you wrote: >> > Earliar ARM clock frequency was calculated by: >> > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. >> > It is fixed by calcuating it as follows: >> >> Um Comment and code disagree: >> >> > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) >> > Yes comment need to be modified. > >> ...or is this just missing a paren? >> >> > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); >> > + dout_apll /= (core2_ratio + 1); >> >> This gives >> >> ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) >> >> Please check if this is correct. >> > > Below is the scenario of selection. > > MOUTAPLL --->| MUX_CORE |>MOUTCORE > MOUTMPLL --->|| > > Here MOUTAPLL is selected as input. So Parent is correct. > > Best regards, >> >> Wolfgang Denk >> >> -- >> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel >> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de >> Bus error -- driver executed. >> > > > > -- > with warm regards, > Chander Kashyap > -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
On 19 December 2011 16:57, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> you > wrote: >> Earliar ARM clock frequency was calculated by: >> MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. >> It is fixed by calcuating it as follows: > > Um Comment and code disagree: > >> ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > ...or is this just missing a paren? > >> + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); >> + dout_apll /= (core2_ratio + 1); > > This gives > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > Please check if this is correct. Wolfgang, you are right. ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) is right. Dear Chander Kashyap, > /* APLL_RATIO: [26:24] */ Please fix this comment also. > - apll_ratio = (div >> 24) & 0x7; > + core_ratio = (div >> 0) & 0x7; > + core2_ratio = (div >> 28) & 0x7; > > - dout_apll = get_pll_clk(APLL) / (apll_ratio + 1); > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); This output is not dout_apll. Please fix it. > + dout_apll /= (core2_ratio + 1); > > return dout_apll; Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Wolfgang Denk, On 19 December 2011 13:27, Wolfgang Denk wrote: > Dear Chander Kashyap, > > In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> > you wrote: > > Earliar ARM clock frequency was calculated by: > > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > > It is fixed by calcuating it as follows: > > Um Comment and code disagree: > > > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) > > ...or is this just missing a paren? > > > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > > + dout_apll /= (core2_ratio + 1); > > This gives > > ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) > > Please check if this is correct. > Below is the scenario of selection. MOUTAPLL --->| MUX_CORE |>MOUTCORE MOUTMPLL --->|| Here MOUTAPLL is selected as input. So Parent is correct. Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > Bus error -- driver executed. > -- with warm regards, Chander Kashyap ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Chander Kashyap, In message <1324275424-29468-3-git-send-email-chander.kash...@linaro.org> you wrote: > Earliar ARM clock frequency was calculated by: > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > It is fixed by calcuating it as follows: Um Comment and code disagree: > ARMCLK=MOUTCORE/(DIVCORE + 1)/DIVCORE2 + 1) ...or is this just missing a paren? > + dout_apll = get_pll_clk(APLL) / (core_ratio + 1); > + dout_apll /= (core2_ratio + 1); This gives ARMCLK=MOUTCORE/(DIVCORE + 1)/ (DIVCORE2 + 1) Please check if this is correct. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Bus error -- driver executed. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
