[PATCH] EXYNOS: Detect cpuid based on Exynos product codes
Exynos based SoC's have two different naming conventions.
One is S5PC_ and other is EXXX_. This patch adds
generic code to handle EXXX_ connvention.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/cpu.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
b/arch/arm/include/asm/arch-exynos/cpu.h
index 89f2c2e..da89ccf 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -105,10 +105,13 @@ static inline void s5p_set_cpu_id(void)
}
}
+#define EXYNOS_ID ((readl(EXYNOS4_PRO_ID) (0xF 24)) 24)
#define IS_SAMSUNG_TYPE(type, id) \
static inline int cpu_is_##type(void) \
{ \
- return s5p_cpu_id == id ? 1 : 0;\
+ return ((s5p_cpu_id == id) \
+ || (EXYNOS_ID == (#type[sizeof(#type) - 2] - '0'))) \
+ ? 1 : 0;\
}
IS_SAMSUNG_TYPE(exynos4, 0xc210)
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5 3/4] clk: introduce the common clock framework
On Tue, Mar 13, 2012 at 04:43:57PM -0700, Turquette, Mike wrote: On Tue, Mar 13, 2012 at 4:24 AM, Sascha Hauer s.ha...@pengutronix.de wrote: On Sat, Mar 03, 2012 at 12:29:00AM -0800, Mike Turquette wrote: The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks. The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations. This patch introduces the common struct clk, struct clk_ops and an implementation of the well-known clock api in include/clk/clk.h. Platforms may define their own hardware-specific clock structure and their own clock operation callbacks, so long as it wraps an instance of struct clk_hw. See Documentation/clk.txt for more details. This patch is based on the work of Jeremy Kerr, which in turn was based on the work of Ben Herrenschmidt. Signed-off-by: Mike Turquette mturque...@linaro.org Signed-off-by: Mike Turquette mturque...@ti.com Cc: Jeremy Kerr jeremy.k...@canonical.com Cc: Thomas Gleixner t...@linutronix.de Cc: Arnd Bergman arnd.bergm...@linaro.org Cc: Paul Walmsley p...@pwsan.com Cc: Shawn Guo shawn@freescale.com Cc: Richard Zhao richard.z...@linaro.org Cc: Saravana Kannan skan...@codeaurora.org Cc: Magnus Damm magnus.d...@gmail.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Linus Walleij linus.wall...@stericsson.com Cc: Stephen Boyd sb...@codeaurora.org Cc: Amit Kucheria amit.kuche...@linaro.org Cc: Deepak Saxena dsax...@linaro.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: Andrew Lunn and...@lunn.ch --- drivers/clk/Kconfig | 28 + drivers/clk/Makefile | 1 + drivers/clk/clk.c | 1323 ++ include/linux/clk-private.h | 68 +++ include/linux/clk-provider.h | 169 ++ include/linux/clk.h | 68 ++- 6 files changed, 1652 insertions(+), 5 deletions(-) create mode 100644 drivers/clk/clk.c create mode 100644 include/linux/clk-private.h create mode 100644 include/linux/clk-provider.h diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 3912576..18eb8c2 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -11,3 +11,31 @@ config HAVE_MACH_CLKDEV config HAVE_CLK_PREPARE bool + +menuconfig COMMON_CLK + bool Common Clock Framework + select HAVE_CLK_PREPARE + ---help--- + The common clock framework is a single definition of struct + clk, useful across many platforms, as well as an + implementation of the clock API in include/linux/clk.h. + Architectures utilizing the common struct clk should select + this automatically, but it may be necessary to manually select + this option for loadable modules requiring the common clock + framework. + + If in doubt, say N. + +if COMMON_CLK + +config COMMON_CLK_DEBUG + bool DebugFS representation of clock tree + depends on COMMON_CLK + ---help--- + Creates a directory hierchy in debugfs for visualizing the clk + tree structure. Each directory contains read-only members + that export information specific to that clk node: clk_rate, + clk_flags, clk_prepare_count, clk_enable_count + clk_notifier_count. + +endif diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 07613fa..ff362c4 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o +obj-$(CONFIG_COMMON_CLK) += clk.o diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c new file mode 100644 index 000..b979d74 --- /dev/null +++ b/drivers/clk/clk.c @@ -0,0 +1,1323 @@ +/* + * Copyright (C) 2010-2011 Canonical Ltd jeremy.k...@canonical.com + * Copyright (C) 2011-2012 Linaro Ltd mturque...@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Standard functionality for the common clock API. See Documentation/clk.txt + */ + +#include linux/clk-private.h +#include linux/module.h +#include linux/mutex.h +#include linux/spinlock.h +#include linux/err.h +#include linux/list.h +#include linux/slab.h + +static DEFINE_SPINLOCK(enable_lock); +static DEFINE_MUTEX(prepare_lock); + +static HLIST_HEAD(clk_root_list); +static HLIST_HEAD(clk_orphan_list); +static LIST_HEAD(clk_notifier_list); + +/*** debugfs support ***/ + +#ifdef CONFIG_COMMON_CLK_DEBUG +#include linux/debugfs.h + +static struct dentry *rootdir; +static struct dentry *orphandir; +static
Re: [PATCH v6 3/3] clk: basic clock hardware types
Hi Mike,
+static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
+ unsigned long *best_parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ int i, bestdiv = 0;
+ unsigned long parent_rate, best = 0, now, maxdiv;
+
+ maxdiv = (1 divider-width);
+
+ if (divider-flags CLK_DIVIDER_ONE_BASED)
+ maxdiv--;
+
+ if (!(__clk_get_flags(hw-clk) CLK_SET_RATE_PARENT)) {
+ parent_rate = __clk_get_rate(__clk_get_parent(hw-clk));
+ bestdiv = parent_rate / rate;
+ bestdiv = bestdiv == 0 ? 1 : bestdiv;
+ bestdiv = bestdiv maxdiv ? maxdiv : bestdiv;
+ goto out;
+ }
+
+ /*
+ * The maximum divider we can use without overflowing
+ * unsigned long in rate * i below
+ */
+ maxdiv = min(ULONG_MAX / rate, maxdiv);
+
+ for (i = 1; i = maxdiv; i++) {
+ int div;
+ parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
+ rate * i);
+ div = parent_rate / rate;
+ div = div maxdiv ? maxdiv : div;
+ div = div 1 ? 1 : div;
+ now = parent_rate / div;
+
+ if (now = rate now = best) {
+ bestdiv = div;
+ best = now;
+ *best_parent_rate = parent_rate;
if (now == rate)
break;
we don't need it to loop to end, and smaller parent_rate is better.
+ }
+ }
+
+ if (!bestdiv) {
+ bestdiv = (1 divider-width);
+ parent_rate = __clk_round_rate(__clk_get_parent(hw-clk), 1);
+ } else {
+ parent_rate = best * bestdiv;
+ }
+
+out:
+ if (best_parent_rate)
+ *best_parent_rate = parent_rate;
+
+ return bestdiv;
+}
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v13] Regulator: Add Anatop regulator driver
On Wed, Mar 14, 2012 at 10:29:12AM +0800, Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org Anatop is an integrated regulator inside i.MX6 SoC. There are 3 digital regulators which controls PU, CORE (ARM), and SOC. And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB). This patch adds the Anatop regulator driver. Applied, thanks. signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h |2 +-
board/samsung/smdk5250/tzpc_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..03e46bb 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct s5p_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h | 2 +-
board/samsung/smdk5250/tzpc_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
Thank you,
Kyungmin Park
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..03e46bb 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct s5p_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h | 2 +-
board/samsung/smdk5250/tzpc_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
Thank you,
Kyungmin Park
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..03e46bb 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct s5p_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET)
{
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
with warm regards,
Chander Kashyap
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[Question] How To Log QEMU Memory Access
Dear linus.walleij, I am sorry to trouble you. Would you mind give a hand? I got a job that should log the RAM memory access in the QEMU. First, I should find out the code line in QEMU to trap all RAM memory access. After some efforts, I have some conclusions: 1. I have found the function dealing with the translation from the virtual address to physical address in the guest of QEMU, such as [target-arm/helper.c:get_phys_addr], and the page fault handler function [target-arm/helper.c:cpu_arm_handle_mmu_fault]. However, we have not found out the routine of accessing physical address from MMU TLB entry. 2. We have understood the relation of the guest physical address and host virtual address, and found the function [exec.c:qemu_get_ram_ptr] translating the guest physical address to host virtual address. I am pressed for time. Would you mind to help me to check it? If you know the location of the code lines or related messages, please tell me. Thank you for your kindness. The QEMU I used getting from [* http://lists.linaro.org/pipermail/linaro-announce/2012-February/95.html* ]. Thanks, Jerry Zhou ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Question] How To Log QEMU Memory Access
On 14 March 2012 14:01, 周春华 uuli...@gmail.com wrote: I got a job that should log the RAM memory access in the QEMU. First, I should find out the code line in QEMU to trap all RAM memory access. After some efforts, I have some conclusions: 1. I have found the function dealing with the translation from the virtual address to physical address in the guest of QEMU, such as [target-arm/helper.c:get_phys_addr], and the page fault handler function [target-arm/helper.c:cpu_arm_handle_mmu_fault]. However, we have not found out the routine of accessing physical address from MMU TLB entry. The TLB lookup and reading of the host RAM is done by generated code (for instance on an x86 host this code is generated by tcg_out_qemu_ld() and tcg_out_qemu_st() in tcg/i386/tcg-target.c). NB that the QEMU TLB goes straight from guest virtual address to host address when it's reading RAM, without passing through a guest physical address. I'm afraid there's no convenient place to put logging of memory accesses in this code, because it is designed for speed rather than ease of instrumentation. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 0/4] omap hsmmc device tree support
Hi, On Mon, Mar 12 2012, Rajendra Nayak wrote: The series adds device tree support for OMAP hsmmc driver. Changes in V2: -1- Minor fixes based on comments from Grant. -2- Added a seperate compatible for omap3. -3- Added a new binding ti,needs-special-reset to handle some mmc modules which need special softreset sequence. -4- Updated board dts files with status = disable; for unused mmc modules. Rob, I retained your ack on patch 1 despite the additional binding that I added to handle the special softreset sequence. Let me know if you have any issues with it. Chris. Patch 1 and Patch 2 apply cleanly on mmc-next and can be taken in from the mmc tree after relevent acks from DT folks. Patch 3 and Patch 4 which update dts files, I plan to push via linux-omap/Tony's tree. Thanks, I've pushed patches 1 and 2 to mmc-next for 3.4, with Balaji's Tested-by. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 3/3] clk: basic clock hardware types
On Fri, Mar 09, 2012 at 11:54:24PM -0800, Mike Turquette wrote:
Many platforms support simple gateable clocks, fixed-rate clocks,
adjustable divider clocks and multi-parent multiplexer clocks.
This patch introduces basic clock types for the above-mentioned hardware
which share some common characteristics.
Based on original work by Jeremy Kerr and contribution by Jamie Iles.
Dividers and multiplexor clocks originally contributed by Richard Zhao
Sascha Hauer.
Signed-off-by: Mike Turquette mturque...@linaro.org
Signed-off-by: Mike Turquette mturque...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Jeremy Kerr jeremy.k...@canonical.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Arnd Bergman arnd.bergm...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Shawn Guo shawn@freescale.com
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Jamie Iles ja...@jamieiles.com
Cc: Richard Zhao richard.z...@linaro.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Deepak Saxena dsax...@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Andrew Lunn and...@lunn.ch
---
Changes since v5:
* standardized the hw-specific locking in the basic clock types
* export the individual ops for each basic clock type
* improve registration for single-parent basic clocks (thanks Sascha)
* fixed bugs in gate clock's static initializers (thanks Andrew)
drivers/clk/Makefile |3 +-
drivers/clk/clk-divider.c| 204
++
drivers/clk/clk-fixed-rate.c | 82 +
drivers/clk/clk-gate.c | 157
drivers/clk/clk-mux.c| 123 +
include/linux/clk-private.h | 124 +
include/linux/clk-provider.h | 127 ++
7 files changed, 819 insertions(+), 1 deletions(-)
create mode 100644 drivers/clk/clk-divider.c
create mode 100644 drivers/clk/clk-fixed-rate.c
create mode 100644 drivers/clk/clk-gate.c
create mode 100644 drivers/clk/clk-mux.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ff362c4..1f736bc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
-obj-$(CONFIG_COMMON_CLK) += clk.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \
+clk-mux.o clk-divider.o
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
new file mode 100644
index 000..c0c4e0b
--- /dev/null
+++ b/drivers/clk/clk-divider.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix s.ha...@pengutronix.de
+ * Copyright (C) 2011 Richard Zhao, Linaro richard.z...@linaro.org
+ * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Adjustable divider clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+
+/*
+ * DOC: basic adjustable divider clock that cannot gate
+ *
+ * Traits of this clock:
+ * prepare - clk_prepare only ensures that parents are prepared
+ * enable - clk_enable only ensures that parents are enabled
+ * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ unsigned int div;
+ unsigned long flags = 0;
+
+ if (divider-lock)
+ spin_lock_irqsave(divider-lock, flags);
+
+ div = readl(divider-reg) divider-shift;
+ div = (1 divider-width) - 1;
+
+ if (divider-lock)
+ spin_unlock_irqrestore(divider-lock, flags);
+
+ if (!(divider-flags CLK_DIVIDER_ONE_BASED))
+ div++;
+
+ return parent_rate / div;
+}
+EXPORT_SYMBOL_GPL(clk_divider_recalc_rate);
+
+static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
+ unsigned long *best_parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ int i, bestdiv = 0;
+ unsigned long parent_rate, best = 0, now, maxdiv;
+
+ maxdiv = (1 divider-width);
We need a check for rate == 0 here:
if (rate == 0)
rate = 1;
Re: [PATCH v6 3/3] clk: basic clock hardware types
On 03/14/2012 01:23 PM, Sascha Hauer wrote:
On Fri, Mar 09, 2012 at 11:54:24PM -0800, Mike Turquette wrote:
Many platforms support simple gateable clocks, fixed-rate clocks,
adjustable divider clocks and multi-parent multiplexer clocks.
This patch introduces basic clock types for the above-mentioned hardware
which share some common characteristics.
Based on original work by Jeremy Kerr and contribution by Jamie Iles.
Dividers and multiplexor clocks originally contributed by Richard Zhao
Sascha Hauer.
Signed-off-by: Mike Turquette mturque...@linaro.org
Signed-off-by: Mike Turquette mturque...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Jeremy Kerr jeremy.k...@canonical.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Arnd Bergman arnd.bergm...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Shawn Guo shawn@freescale.com
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Jamie Iles ja...@jamieiles.com
Cc: Richard Zhao richard.z...@linaro.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Deepak Saxena dsax...@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Andrew Lunn and...@lunn.ch
---
Changes since v5:
* standardized the hw-specific locking in the basic clock types
* export the individual ops for each basic clock type
* improve registration for single-parent basic clocks (thanks Sascha)
* fixed bugs in gate clock's static initializers (thanks Andrew)
drivers/clk/Makefile |3 +-
drivers/clk/clk-divider.c| 204
++
drivers/clk/clk-fixed-rate.c | 82 +
drivers/clk/clk-gate.c | 157
drivers/clk/clk-mux.c| 123 +
include/linux/clk-private.h | 124 +
include/linux/clk-provider.h | 127 ++
7 files changed, 819 insertions(+), 1 deletions(-)
create mode 100644 drivers/clk/clk-divider.c
create mode 100644 drivers/clk/clk-fixed-rate.c
create mode 100644 drivers/clk/clk-gate.c
create mode 100644 drivers/clk/clk-mux.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ff362c4..1f736bc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
-obj-$(CONFIG_COMMON_CLK)+= clk.o
+obj-$(CONFIG_COMMON_CLK)+= clk.o clk-fixed-rate.o clk-gate.o \
+ clk-mux.o clk-divider.o
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
new file mode 100644
index 000..c0c4e0b
--- /dev/null
+++ b/drivers/clk/clk-divider.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix s.ha...@pengutronix.de
+ * Copyright (C) 2011 Richard Zhao, Linaro richard.z...@linaro.org
+ * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd
mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Adjustable divider clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+
+/*
+ * DOC: basic adjustable divider clock that cannot gate
+ *
+ * Traits of this clock:
+ * prepare - clk_prepare only ensures that parents are prepared
+ * enable - clk_enable only ensures that parents are enabled
+ * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+struct clk_divider *divider = to_clk_divider(hw);
+unsigned int div;
+unsigned long flags = 0;
+
+if (divider-lock)
+spin_lock_irqsave(divider-lock, flags);
+
+div = readl(divider-reg) divider-shift;
+div = (1 divider-width) - 1;
+
+if (divider-lock)
+spin_unlock_irqrestore(divider-lock, flags);
+
+if (!(divider-flags CLK_DIVIDER_ONE_BASED))
+div++;
+
+return parent_rate / div;
+}
+EXPORT_SYMBOL_GPL(clk_divider_recalc_rate);
+
+static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
+unsigned long *best_parent_rate)
+{
+struct clk_divider *divider = to_clk_divider(hw);
+int i, bestdiv = 0;
+unsigned long parent_rate, best = 0, now, maxdiv;
+
+maxdiv = (1 divider-width);
We need a check for rate == 0 here:
if (rate == 0)
Announce: live-build a45
Located in ppa:linaro-maintainers/tools can be found the newest version of live-build, a45 with the following linaro features applied: 1) armhf support (both native and cross) 2) linaro meta bld information as was discussed at 4Q11 Linaro Connect 3) cross support using multistrap Live build a45 supports Maverick, Natty, Oneiric and Precise. With you are you able to build your own images native on an armel or armhf host or cross using either an i386 or x86_64 host creating either armel or armhf targets. For image targets up to oneiric, one is not able to cross assemble the ubuntu-desktop image. However with precise all linaro images including the ubuntu-desktop image can be cross assembled. Enjoy! -- Regards, Tom Where's the kaboom!? There was supposed to be an earth-shattering kaboom! Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Slow/broken USB and Ethernet on Snowballs/Origen boards?
Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 1) i.MX 53 * disk I/O using an external SSD drive is very good; good enough to not require further measurements * network I/O is approximately 9-10 MByte/s (perhaps more) which seems ok given the 100 MBit/s Ethernet interface 2) Snowball (PDK, version 8) * it seems to be impossible to get the USB OTG host mode to work, therefore I could not test disk I/O with a USB drive; it appears the OTG port on the version 8 board does not even have enough power for a powered USB to actually go online (I am unaware of the details of how this works unfortunately) * performing network I/O with netcat casues netcat, ksoftirqd and kworker to use ~33% of the CPU each, resulting in 100% CPU usage only to handle the network data transfer * the resulting network transfer rate is about 5.5 MByte/s, which is significantly less than what the 100 MBit/s Ethernet interface should be able to produce 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway I guess not all of this is surprising. The i.MX performs quite well but unfortunately the CPU is quite slow compared to the others. However, I wonder whether the USB OTG host mode issue on the Snowball is a known problem? Also, network I/O occupying all of the CPU seems to be a bug or at least a dodgy driver. About the Origen: I assume there is nothing that can be done to have High Speed USB on it? Thanks in advance! If anyone needs me to provide more information, I'll gladly try to do that. Regards, Jannis ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5 3/4] clk: introduce the common clock framework
On Wed, Mar 14, 2012 at 1:48 AM, Sascha Hauer s.ha...@pengutronix.de wrote: On Tue, Mar 13, 2012 at 04:43:57PM -0700, Turquette, Mike wrote: On Tue, Mar 13, 2012 at 4:24 AM, Sascha Hauer s.ha...@pengutronix.de wrote: On Sat, Mar 03, 2012 at 12:29:00AM -0800, Mike Turquette wrote: The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks. The net result is consolidation of many different struct clk definitions and platform-specific clock framework implementations. This patch introduces the common struct clk, struct clk_ops and an implementation of the well-known clock api in include/clk/clk.h. Platforms may define their own hardware-specific clock structure and their own clock operation callbacks, so long as it wraps an instance of struct clk_hw. See Documentation/clk.txt for more details. This patch is based on the work of Jeremy Kerr, which in turn was based on the work of Ben Herrenschmidt. Signed-off-by: Mike Turquette mturque...@linaro.org Signed-off-by: Mike Turquette mturque...@ti.com Cc: Jeremy Kerr jeremy.k...@canonical.com Cc: Thomas Gleixner t...@linutronix.de Cc: Arnd Bergman arnd.bergm...@linaro.org Cc: Paul Walmsley p...@pwsan.com Cc: Shawn Guo shawn@freescale.com Cc: Richard Zhao richard.z...@linaro.org Cc: Saravana Kannan skan...@codeaurora.org Cc: Magnus Damm magnus.d...@gmail.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Linus Walleij linus.wall...@stericsson.com Cc: Stephen Boyd sb...@codeaurora.org Cc: Amit Kucheria amit.kuche...@linaro.org Cc: Deepak Saxena dsax...@linaro.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: Andrew Lunn and...@lunn.ch --- drivers/clk/Kconfig | 28 + drivers/clk/Makefile | 1 + drivers/clk/clk.c | 1323 ++ include/linux/clk-private.h | 68 +++ include/linux/clk-provider.h | 169 ++ include/linux/clk.h | 68 ++- 6 files changed, 1652 insertions(+), 5 deletions(-) create mode 100644 drivers/clk/clk.c create mode 100644 include/linux/clk-private.h create mode 100644 include/linux/clk-provider.h diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index 3912576..18eb8c2 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -11,3 +11,31 @@ config HAVE_MACH_CLKDEV config HAVE_CLK_PREPARE bool + +menuconfig COMMON_CLK + bool Common Clock Framework + select HAVE_CLK_PREPARE + ---help--- + The common clock framework is a single definition of struct + clk, useful across many platforms, as well as an + implementation of the clock API in include/linux/clk.h. + Architectures utilizing the common struct clk should select + this automatically, but it may be necessary to manually select + this option for loadable modules requiring the common clock + framework. + + If in doubt, say N. + +if COMMON_CLK + +config COMMON_CLK_DEBUG + bool DebugFS representation of clock tree + depends on COMMON_CLK + ---help--- + Creates a directory hierchy in debugfs for visualizing the clk + tree structure. Each directory contains read-only members + that export information specific to that clk node: clk_rate, + clk_flags, clk_prepare_count, clk_enable_count + clk_notifier_count. + +endif diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 07613fa..ff362c4 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o +obj-$(CONFIG_COMMON_CLK) += clk.o diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c new file mode 100644 index 000..b979d74 --- /dev/null +++ b/drivers/clk/clk.c @@ -0,0 +1,1323 @@ +/* + * Copyright (C) 2010-2011 Canonical Ltd jeremy.k...@canonical.com + * Copyright (C) 2011-2012 Linaro Ltd mturque...@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Standard functionality for the common clock API. See Documentation/clk.txt + */ + +#include linux/clk-private.h +#include linux/module.h +#include linux/mutex.h +#include linux/spinlock.h +#include linux/err.h +#include linux/list.h +#include linux/slab.h + +static DEFINE_SPINLOCK(enable_lock); +static DEFINE_MUTEX(prepare_lock); + +static HLIST_HEAD(clk_root_list); +static HLIST_HEAD(clk_orphan_list); +static LIST_HEAD(clk_notifier_list); + +/*** debugfs support ***/ + +#ifdef CONFIG_COMMON_CLK_DEBUG +#include linux/debugfs.h +
Re: [PATCH v5 3/4] clk: introduce the common clock framework
On Wed, Mar 14, 2012 at 2:28 PM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 14 Mar 2012, Turquette, Mike wrote: Could you folks please trim your replies? It's annoying to page down a gazillion of lines to find the gist. Sure. My mailer does this for me so I forget to do it sometimes... On Wed, Mar 14, 2012 at 1:48 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Also, do you forsee needing hole in parent_names for any reason other than described above? I need it only for the case where a some values in the mux are marked as reserved in the datasheet or we simply do not have the corresponding clock in our tree (yet). We could also say that NULL pointers are not allowed in parent arrays, but instead orphan or dummy should be used. Then __clk_init should check for NULL pointers to make this clear. I've added a WARN in __clk_init if any entries in .parent_names are NULL. I think it best to populate it with dummy, or maybe a platform-specific name if it helps you during development. There is no guarantee that the selection of a parent can be mapped linear to register values. Agreed. I have always viewed .parent_names as only a list of the names of all possible parents, nothing more. And of course its array indexing should line up with struct clk **parents. So the right way to deal with it is to have an array of valid names with no holes and NULL pointers allowed and have a mapping from the array index to the register value. This is essentially what the .set_rate callback does. It takes as input u8 index and peforms the hardware specific magic to select the correct parent clock. This might be a register write using that exact same index, or it might be a single-bit register write using that index as the shift value, or it might translate that index into the data sent to an i2c device (where the address would be stored in struct clk_foo), etc etc. We both agree that .parent_names must contain valid names and should not have holes. What I don't understand is if you are saying that we should allow NULL ptrs as names; that seems contradictory but I want to make sure I'm reading you correctly. Thanks, Mike That makes the core code robust and allows to handle all corner cases including reserved bits, not implemented clocks and weird register layouts. Thanks, tglx ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5 3/4] clk: introduce the common clock framework
On Wed, 14 Mar 2012, Turquette, Mike wrote: Could you folks please trim your replies? It's annoying to page down a gazillion of lines to find the gist. On Wed, Mar 14, 2012 at 1:48 AM, Sascha Hauer s.ha...@pengutronix.de wrote: Also, do you forsee needing hole in parent_names for any reason other than described above? I need it only for the case where a some values in the mux are marked as reserved in the datasheet or we simply do not have the corresponding clock in our tree (yet). We could also say that NULL pointers are not allowed in parent arrays, but instead orphan or dummy should be used. Then __clk_init should check for NULL pointers to make this clear. I've added a WARN in __clk_init if any entries in .parent_names are NULL. I think it best to populate it with dummy, or maybe a platform-specific name if it helps you during development. There is no guarantee that the selection of a parent can be mapped linear to register values. So the right way to deal with it is to have an array of valid names with no holes and NULL pointers allowed and have a mapping from the array index to the register value. That makes the core code robust and allows to handle all corner cases including reserved bits, not implemented clocks and weird register layouts. Thanks, tglx ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v5 3/4] clk: introduce the common clock framework
On Wed, 14 Mar 2012, Turquette, Mike wrote: On Wed, Mar 14, 2012 at 2:28 PM, Thomas Gleixner t...@linutronix.de wrote: So the right way to deal with it is to have an array of valid names with no holes and NULL pointers allowed and have a mapping from the array index to the register value. This is essentially what the .set_rate callback does. It takes as input u8 index and peforms the hardware specific magic to select the correct parent clock. This might be a register write using that exact same index, or it might be a single-bit register write using that index as the shift value, or it might translate that index into the data sent to an i2c device (where the address would be stored in struct clk_foo), etc etc. We both agree that .parent_names must contain valid names and should not have holes. What I don't understand is if you are saying that we should allow NULL ptrs as names; that seems contradictory but I want to make sure I'm reading you correctly. I should have said: no holes and no NULL pointers, just an array of valid names. Thanks, tglx ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 2/3] clk: introduce the common clock framework
On Tue, Mar 13, 2012 at 5:05 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Mar 12, 2012 at 08:16:36PM -0700, Turquette, Mike wrote:
On Mon, Mar 12, 2012 at 4:51 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
I tried another
approach on the weekend which basically does not try to do all in a
single recursion but instead sets the rate in multiple steps:
1) call a function which calculates all new rates of affected clocks
in a rate change and safes the value in a clk-new_rate field. This
function returns the topmost clock which has to be changed.
2) starting from the topmost clock notify all clients. This walks the
whole subtree even if a notfifier refuses the change. If necessary
we can walk the whole subtree again to abort the change.
3) actually change rates starting from the topmost clocks and notify
all clients on the way. I changed the set_rate callback to void.
Instead of failing (what is failing in case of set_rate? The clock
will still have some rate) I check for the result with
clk_ops-recalc_rate.
The way described above works for me now, see this branch:
git://git.pengutronix.de/git/imx/linux-2.6.git v3.3-rc6-clkv6-fixup
You may not necessarily like it as it changes quite a lot in the rate
changing code.
I tried that code and I really like it! It is much more readable and
feels less fragile than the previous recursive __clk_set_rate. I
did quite a bit of testing with this code today. One of the tests
looks like this:
pll (adjustable to anything)
|
clk_divider (5 bits wide)
|
dummy(no clk_ops)
The new code did a fine job arbitrating rates for the PLL and the
intermediate divider even if I put weird constraints on the PLL. For
instance if I artificially limited it to a minimum of 600MHz and then
ran clk_set_rate(dummy, 300MHz) it would lock at 600MHz and set
clk_divider to divide-by-2. Setting to 600MHz or more set the divider
back to 1 and relocked the PLL appropriately. Pretty cool.
I also tested the notifiers with this code and they seem to function
properly. I'll take this code in for v7. Thanks a lot for this
helpful contribution.
I did find that MULT_ROUND_UP caused trouble for my PLL's round_rate
implementation. Maybe my PLL code is fragile but a quick fix was to
make sure that we send the exact value we want to the round_rate code.
I also feel this is more correct. Let me know what you think:
8---
commit 189fecedb175d0366759246c4192f45b0bc39a50
Author: Mike Turquette mturque...@linaro.org
Date: Wed Mar 14 17:29:51 2012 -0700
clk-divider.c: round the actual rate we care about
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 86ca9cd..06ef4a0 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -47,12 +47,6 @@ static unsigned long clk_divider_recalc_rate(struct
clk_hw *hw,
}
EXPORT_SYMBOL_GPL(clk_divider_recalc_rate);
-/*
- * The reverse of DIV_ROUND_UP: The maximum number which
- * divided by m is r
- */
-#define MULT_ROUND_UP(r, m) ((r) * (m) + (m) - 1)
-
static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate)
{
@@ -84,9 +78,9 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
for (i = 1; i = maxdiv; i++) {
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
- MULT_ROUND_UP(rate, i));
+ (rate * i));
now = parent_rate / i;
- if (now = rate now = best) {
+ if (now = rate now best) {
bestdiv = i;
best = now;
*best_parent_rate = parent_rate;
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
Dear Minkyu,
On 15 March 2012 06:53, Minkyu Kang proms...@gmail.com wrote:
Dear Chander Kashyap,
On 14 March 2012 22:38, Chander Kashyap chander.kash...@linaro.org wrote:
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h | 2 +-
board/samsung/smdk5250/tzpc_init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
I agreed with Kyungmin.
From now, let's called exynos for common name including s5pc1xx and
s5pc2xx and exynos4 and exynos5.. etc.
Thanks for the inputs. Let us follow the convention. I will resubmit the patch.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
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
[PATCH v2] EXYNOS: Rename exynos5_tzpc structure to exynos_tzpc
TZPC IP is common across Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to exynos_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use exynos_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes in V2:
- Renaming is changed from s5p_ctzpc to exynos_tzpc as per
Kyungmin's Comments.
arch/arm/include/asm/arch-exynos/tzpc.h |2 +-
board/samsung/smdk5250/tzpc_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..c5eb4b1 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct exynos_tzpc {
unsigned int r0size;
char res1[0x7FC];
unsigned int decprot0stat;
diff --git a/board/samsung/smdk5250/tzpc_init.c
b/board/samsung/smdk5250/tzpc_init.c
index c2ccef3..f39bd55 100644
--- a/board/samsung/smdk5250/tzpc_init.c
+++ b/board/samsung/smdk5250/tzpc_init.c
@@ -28,7 +28,7 @@
/* Setting TZPC[TrustZone Protection Controller] */
void tzpc_init(void)
{
- struct exynos5_tzpc *tzpc;
+ struct exynos_tzpc *tzpc;
unsigned int addr;
for (addr = TZPC0_BASE; addr = TZPC9_BASE; addr += TZPC_BASE_OFFSET) {
--
1.7.5.4
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Samsung] [U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
On 03/15/2012 06:53 AM, Minkyu Kang wrote:
Dear Chander Kashyap,
On 14 March 2012 22:38, Chander Kashyap chander.kash...@linaro.org wrote:
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h |2 +-
board/samsung/smdk5250/tzpc_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
I agreed with Kyungmin.
From now, let's called exynos for common name including s5pc1xx and
s5pc2xx and exynos4 and exynos5.. etc.
From the above list, only s5pc1xx series was not named EXYNOS.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
Thanks
Minkyu Kang.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
