* [RFC PATCH 1/1] ARM: imx5x: clean up ARCH_MX5X
From: Richard Zhao @ 2011-03-03 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302163326.GG22310@pengutronix.de>
Hi Uwe,
On Wed, Mar 02, 2011 at 05:33:26PM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Mar 03, 2011 at 12:06:05AM +0800, Richard Zhao wrote:
> > Hi Uwe,
> >
> > Thanks for your detailed explanation!
> > On Wed, Mar 02, 2011 at 12:25:59PM +0100, Uwe Kleine-K?nig wrote:
> > > Hello Richard,
> > >
> > > On Wed, Mar 02, 2011 at 11:28:46AM +0800, Richard Zhao wrote:
> > > > Remove legacy support of ARCH_MX5X. Move to SOC_SOC_IMX5X.
> > > >
> > > > My understanding is ARCH_MX5 selects Kconfig in arch/arm/mach-mx5,
> > > > and every board can be selected/unselected, and SOC_XXX be selected
> > > > by the board config. MACH_XXXX/SOC_XXXX then select those HAVE_XXXX.
> > > My intended goal with these ARCH_MX.., MACH_MX.. and SOC_IMX.. symbols is:
> > >
> > > - ARCH_MX.. should be only a helper to group all machines together that
> > > can be built in a single image. In the far future it hopefully dies
> > > because we can compile everything together. These IMHO should not be
> > > used in Makefiles or source files at all as the grouping can change
> > > over time. I'm not sure the name ARCH_MX.. is that good. Didn't think
> > > about a better naming scheme, so if you have suggestions don't
> > > hesitate to tell them.
> > Would it make sense to go straight forward?
> > ARCH_MX.. for SoC series. eg. ARCH_MX1/2/3/5. It groups SoCs.
> This doesn't work. Where do you want to put i.MX25? Conceptually the
> easy groups are { i.MX21, i.MX27 } and { i.MX25, i.MX31, i.MX35 }
> because these share PHYS_OFFSETs. And note that i.MX31 has a different
> iomuxer than i.MX25 and i.MX35. As soon as we have support for runtime
> PHYS_OFFSET the remaining groups are:
>
> ARMv4 + ARMv5 vs. ARMv6 + ARMv7
>
> (I think) which doesn't match the ARCH_MX1/2/3/5 approach anymore.
I see, you goup it by same features.
>
> > SOC_IMX.. for single SoC. eg. SOC_IMX31/35/50/51/53. It groups Machines.
> > MACH_.. for single machine. eg. MACH_MX51_BABBAGE.
> >
> > They can be used in Makefiles to help include source files, but idealy not be
> > used in source files. For multi-soc in single image, it's more easy to select
> > build targets. It can also help transit to single image step by step.
> Here I'd prefer things like:
>
> config SOC_IMX21
> bool
> select IMX_HAVE_IOMUX_V1
>
> obj-$(IMX_HAVE_IOMUX_V1) += tralala.o
>
> > > - MACH_MX.. actually are misnomers becauce they clash with the name
> > > space of the machine db. So they should be substituted by SOC_IMX...
> > > (maybe a few by ARCH_MX..) (affected: MACH_MX21 and MACH_MX27)
> > > - SOC_IMX.. are used to differentiate between SoCs.
> > >
> > > So a goal is to review all ARCH_MX.. and MACH_MX.. used in .c and .h
> > > files and try to use the SOC_IMX variables instead.
> > > Here I consider important that SOC_IMX... is really only used with
> > > having multi-SoC-kernels in mind. So you can consider ARCH_MX and
> > > MACH_MX as todo-markers for that (and this is the main difference IMHO).
> > > E.g. the Makefile.boots are such a place that are not multi-soc capable
> > > yet as is the selection of PHYS_OFFSET. I'd like to keep them marked
> > > somehow.
> > The ToDO markers might label itself as markers, Or it cause many people
> > confused.
> I don't know what you mean here.
I mean need more comments at:
if ARCH_MX5
# ARCH_MX51 and ARCH_MX50 are left for compatibility
>
> > And are you sure we won't need ARCH_MX.. in the final single image solution?
> > IMHO, single image needs to select what targetis it builds for too. The ARCH_MX..
> > works as categories and help reduce image size.
> Again, I don't understand you here.
I mean ARCH_MX1/2/3 is easy to group SoCs and boards, and esay to select the set
of SoCs/Boards I want to build the kernel for.
>
> > > I don't know if it's sensible to coordinate this effort, it mainly
> > > depends on how many people are willing to help. I'll start with ARCH_MX2
> > > and MACH_MX2[17] next.
> > >
> > > A bit orthogonal to this issue is to clean up mach-mx3 and mach-mx5 to
> > > allow them to be merged into mach-imx. I didn't look at all on mxc91231,
> > > yet.
> > >
> > > Comments and patches are welcome. If you want to help and don't know
> > > where to start, here are a few hints:
> > >
> > > - git grep -E 'M?AR?CH_MX' drivers
> > > - convert arch/arm/mach-mx[35]/devices.c to dynamically allocation
> > >
> > > Richard, having said that, some of your changes look OK, while I'm not
> > > completely happy with the others.
> > It seems only PHYS_OFFSET are not ok?
> and Makefile.boot
ok. so, I will send out patch leaving the two places unchanged.
Thanks
Richard
>
> > Maybe the p2v patch can help?
> Indeed.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* [PATCH 2/2] clk: Generic support for fixed-rate clocks
From: Jeremy Kerr @ 2011-03-03 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299134429.100626.661279191478.0.gpush@pororo>
Since most platforms will need a fixed-rate clock, add one. This will
also serve as a basic example of an implementation of struct clk.
Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
---
drivers/clk/clk.c | 14 ++++++++++++++
include/linux/clk.h | 16 ++++++++++++++++
2 files changed, 30 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 0bc9c6f..0da0bb9 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -130,3 +130,17 @@ void __clk_put(struct clk *clk)
if (clk->ops->put)
clk->ops->put(clk);
}
+
+/* clk_fixed support */
+
+#define to_clk_fixed(clk) (container_of(clk, struct clk_fixed, clk))
+
+static unsigned long clk_fixed_get_rate(struct clk *clk)
+{
+ return to_clk_fixed(clk)->rate;
+}
+
+struct clk_ops clk_fixed_ops = {
+ .get_rate = clk_fixed_get_rate,
+};
+EXPORT_SYMBOL_GPL(clk_fixed_ops);
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 7b406bd..d2f0db0 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -155,6 +155,22 @@ static inline void clk_common_init(struct clk *clk)
mutex_init(&clk->prepare_lock);
}
+/* Simple fixed-rate clock */
+struct clk_fixed {
+ struct clk clk;
+ unsigned long rate;
+};
+
+extern struct clk_ops clk_fixed_ops;
+
+#define INIT_CLK_FIXED(name, r) { \
+ .clk = INIT_CLK(name.clk, clk_fixed_ops), \
+ .rate = (r) \
+}
+
+#define DEFINE_CLK_FIXED(name, r) \
+ struct clk_fixed name = INIT_CLK_FIXED(name, r)
+
#else /* !CONFIG_USE_COMMON_STRUCT_CLK */
/*
^ permalink raw reply related
* [PATCH 1/2] Add a common struct clk
From: Jeremy Kerr @ 2011-03-03 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299134429.100626.661279191478.0.gpush@pororo>
We currently have ~21 definitions of struct clk in the ARM architecture,
each defined on a per-platform basis. This makes it difficult to define
platform- (or architecture-) independent clock sources without making
assumptions about struct clk, and impossible to compile two
platforms with different struct clks into a single image.
This change is an effort to unify struct clk where possible, by defining
a common struct clk, containing a set of clock operations. Different
clock implementations can set their own operations, and have a standard
interface for generic code. The callback interface is exposed to the
kernel proper, while the clock implementations only need to be seen by
the platform internals.
This allows us to share clock code among platforms, and makes it
possible to dynamically create clock devices in platform-independent
code.
Platforms can enable the generic struct clock through
CONFIG_USE_COMMON_STRUCT_CLK. In this case, the clock infrastructure
consists of a common struct clk:
struct clk {
const struct clk_ops *ops;
unsigned int enable_count;
unsigned int prepare_count;
spinlock_t enable_lock;
struct mutex prepare_lock;
};
And a set of clock operations (defined per type of clock):
struct clk_ops {
int (*enable)(struct clk *);
void (*disable)(struct clk *);
unsigned long (*get_rate)(struct clk *);
[...]
};
To define a hardware-specific clock, machine code can "subclass" the
struct clock into a new struct (adding any device-specific data), and
provide a set of operations:
struct clk_foo {
struct clk clk;
void __iomem *some_register;
};
struct clk_ops clk_foo_ops = {
.get_rate = clk_foo_get_rate,
};
The common clock definitions are based on a development patch from Ben
Herrenschmidt <benh@kernel.crashing.org>.
Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
---
drivers/clk/Kconfig | 3
drivers/clk/Makefile | 1
drivers/clk/clk.c | 132 ++++++++++++++++++++++++++++++++++
drivers/clk/clkdev.c | 7 +
include/linux/clk.h | 164 ++++++++++++++++++++++++++++++++++++++++---
5 files changed, 298 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 4168c88..6e3ae54 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -2,3 +2,6 @@
config CLKDEV_LOOKUP
bool
select HAVE_CLK
+
+config USE_COMMON_STRUCT_CLK
+ bool
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 07613fa..a1a06d3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
+obj-$(CONFIG_USE_COMMON_STRUCT_CLK) += clk.o
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
new file mode 100644
index 0000000..0bc9c6f
--- /dev/null
+++ b/drivers/clk/clk.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright (C) 2010-2011 Canonical Ltd <jeremy.kerr@canonical.com>
+ *
+ * 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.
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+
+int clk_prepare(struct clk *clk)
+{
+ int ret = 0;
+
+ mutex_lock(&clk->prepare_lock);
+ if (clk->prepare_count == 0 && clk->ops->prepare)
+ ret = clk->ops->prepare(clk);
+
+ if (!ret)
+ clk->prepare_count++;
+ mutex_unlock(&clk->prepare_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(clk_prepare);
+
+void clk_unprepare(struct clk *clk)
+{
+ mutex_lock(&clk->prepare_lock);
+
+ WARN_ON(clk->prepare_count == 0);
+
+ if (--clk->prepare_count == 0 && clk->ops->unprepare) {
+ WARN_ON(clk->enable_count != 0);
+ clk->ops->unprepare(clk);
+ }
+
+ mutex_unlock(&clk->prepare_lock);
+}
+EXPORT_SYMBOL_GPL(clk_unprepare);
+
+int clk_enable(struct clk *clk)
+{
+ unsigned long flags;
+ int ret = 0;
+
+ WARN_ON(clk->prepare_count == 0);
+
+ spin_lock_irqsave(&clk->enable_lock, flags);
+ if (clk->enable_count == 0 && clk->ops->enable)
+ ret = clk->ops->enable(clk);
+
+ if (!ret)
+ clk->enable_count++;
+ spin_unlock_irqrestore(&clk->enable_lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(clk_enable);
+
+void clk_disable(struct clk *clk)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&clk->enable_lock, flags);
+
+ WARN_ON(clk->enable_count == 0);
+
+ if (!--clk->enable_count == 0 && clk->ops->disable)
+ clk->ops->disable(clk);
+
+ spin_unlock_irqrestore(&clk->enable_lock, flags);
+}
+EXPORT_SYMBOL_GPL(clk_disable);
+
+unsigned long clk_get_rate(struct clk *clk)
+{
+ if (clk->ops->get_rate)
+ return clk->ops->get_rate(clk);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(clk_get_rate);
+
+long clk_round_rate(struct clk *clk, unsigned long rate)
+{
+ if (clk->ops->round_rate)
+ return clk->ops->round_rate(clk, rate);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(clk_round_rate);
+
+int clk_set_rate(struct clk *clk, unsigned long rate)
+{
+ might_sleep();
+
+ if (clk->ops->set_rate)
+ return clk->ops->set_rate(clk, rate);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(clk_set_rate);
+
+int clk_set_parent(struct clk *clk, struct clk *parent)
+{
+ if (clk->ops->set_parent)
+ return clk->ops->set_parent(clk, parent);
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(clk_set_parent);
+
+struct clk *clk_get_parent(struct clk *clk)
+{
+ if (clk->ops->get_parent)
+ return clk->ops->get_parent(clk);
+ return ERR_PTR(-ENOSYS);
+}
+EXPORT_SYMBOL_GPL(clk_get_parent);
+
+int __clk_get(struct clk *clk)
+{
+ if (clk->ops->get)
+ return clk->ops->get(clk);
+ return 1;
+}
+
+void __clk_put(struct clk *clk)
+{
+ if (clk->ops->put)
+ clk->ops->put(clk);
+}
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 0fc0a79..a7999d2 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -23,6 +23,13 @@
static LIST_HEAD(clocks);
static DEFINE_MUTEX(clocks_mutex);
+/* For USE_COMMON_STRUCT_CLK, these are provided in clk.c, but not exported
+ * through other headers; we don't want them used anywhere but here. */
+#ifdef CONFIG_USE_COMMON_STRUCT_CLK
+extern int __clk_get(struct clk *clk);
+extern void __clk_put(struct clk *clk);
+#endif
+
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy matching here:
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 1d37f42..7b406bd 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -3,6 +3,7 @@
*
* Copyright (C) 2004 ARM Limited.
* Written by Deep Blue Solutions Limited.
+ * Copyright (c) 2010-2011 Jeremy Kerr <jeremy.kerr@canonical.com>
*
* 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
@@ -11,18 +12,168 @@
#ifndef __LINUX_CLK_H
#define __LINUX_CLK_H
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/spinlock.h>
+
struct device;
-/*
- * The base API.
+#ifdef CONFIG_USE_COMMON_STRUCT_CLK
+
+/* If we're using the common struct clk, we define the base clk object here */
+
+/**
+ * struct clk - hardware independent clock structure
+ * @ops: implementation-specific ops for this clock
+ * @enable_count: count of clk_enable() calls active on this clock
+ * @enable_lock: lock for atomic enable
+ * @prepare_count: count of clk_prepare() calls active on this clock
+ * @prepare_lock: lock for sleepable prepare
+ *
+ * The base clock object, used by drivers for hardware-independent manipulation
+ * of clock lines. This will be 'subclassed' by device-specific implementations,
+ * which add device-specific data to struct clk. For example:
+ *
+ * struct clk_foo {
+ * struct clk;
+ * [device specific fields]
+ * };
+ *
+ * The clock driver code will manage the device-specific data, and pass
+ * clk_foo.clk to the common clock code. The clock driver will be called
+ * through the @ops callbacks.
+ *
+ * The @enable_lock and @prepare_lock members are used to serialise accesses
+ * to the ops->enable and ops->prepare functions (and the corresponding
+ * ops->disable and ops->unprepare functions).
*/
+struct clk {
+ const struct clk_ops *ops;
+ unsigned int enable_count;
+ unsigned int prepare_count;
+ spinlock_t enable_lock;
+ struct mutex prepare_lock;
+};
+/* static initialiser for clocks. */
+#define INIT_CLK(name, o) { \
+ .ops = &o, \
+ .enable_lock = __SPIN_LOCK_UNLOCKED(name.enable_lock), \
+ .prepare_lock = __MUTEX_INITIALIZER(name.prepare_lock), \
+}
+
+/**
+ * struct clk_ops - Callback operations for clocks; these are to be provided
+ * by the clock implementation, and will be called by drivers through the clk_*
+ * API.
+ *
+ * @prepare: Prepare the clock for enabling. This must not return until
+ * the clock is fully prepared, and it's safe to call clk_enable.
+ * This callback is intended to allow clock implementations to
+ * do any initialisation that may sleep. Called with
+ * clk->prepare_lock held.
+ *
+ * @unprepare: Release the clock from its prepared state. This will typically
+ * undo any work done in the @prepare callback. Called with
+ * clk->prepare_lock held.
+ *
+ * @enable: Enable the clock atomically. This must not return until the
+ * clock is generating a valid clock signal, usable by consumer
+ * devices. Called with clk->enable_lock held. This function
+ * must not sleep.
+ *
+ * @disable: Disable the clock atomically. Called with clk->enable_lock held.
+ * This function must not sleep.
+ *
+ * @get: Called by the core clock code when a device driver acquires a
+ * clock via clk_get(). Optional.
+ *
+ * @put: Called by the core clock code when a devices driver releases a
+ * clock via clk_put(). Optional.
+ *
+ * The clk_enable/clk_disable and clk_prepare/clk_unprepare pairs allow
+ * implementations to split any work between atomic (enable) and sleepable
+ * (prepare) contexts. If a clock requires sleeping code to be turned on, this
+ * should be done in clk_prepare. Switching that will not sleep should be done
+ * in clk_enable.
+ *
+ * Typically, drivers will call clk_prepare when a clock may be needed later
+ * (eg. when a device is opened), and clk_enable when the clock is actually
+ * required (eg. from an interrupt). Note that clk_prepare *must* have been
+ * called before clk_enable.
+ *
+ * For other callbacks, see the corresponding clk_* functions. Parameters and
+ * return values are passed directly from/to these API functions, or
+ * -ENOSYS (or zero, in the case of clk_get_rate) is returned if the callback
+ * is NULL, see drivers/clk/clk.c for implementation details. All are optional.
+ */
+struct clk_ops {
+ int (*prepare)(struct clk *);
+ void (*unprepare)(struct clk *);
+ int (*enable)(struct clk *);
+ void (*disable)(struct clk *);
+ int (*get)(struct clk *);
+ void (*put)(struct clk *);
+ unsigned long (*get_rate)(struct clk *);
+ long (*round_rate)(struct clk *, unsigned long);
+ int (*set_rate)(struct clk *, unsigned long);
+ int (*set_parent)(struct clk *, struct clk *);
+ struct clk * (*get_parent)(struct clk *);
+};
+
+/**
+ * clk_prepare - prepare clock for atomic enabling.
+ *
+ * @clk: The clock to prepare
+ *
+ * Do any possibly sleeping initialisation on @clk, allowing the clock to be
+ * later enabled atomically (via clk_enable). This function may sleep.
+ */
+int clk_prepare(struct clk *clk);
+
+/**
+ * clk_unprepare - release clock from prepared state
+ *
+ * @clk: The clock to release
+ *
+ * Do any (possibly sleeping) cleanup on clk. This function may sleep.
+ */
+void clk_unprepare(struct clk *clk);
+
+/**
+ * clk_common_init - initialise a clock for driver usage
+ *
+ * @clk: The clock to initialise
+ *
+ * Used for runtime intialization of clocks; you don't need to call this
+ * if your clock has been (statically) initialized with INIT_CLK.
+ */
+static inline void clk_common_init(struct clk *clk)
+{
+ clk->enable_count = clk->prepare_count = 0;
+ spin_lock_init(&clk->enable_lock);
+ mutex_init(&clk->prepare_lock);
+}
+
+#else /* !CONFIG_USE_COMMON_STRUCT_CLK */
/*
- * struct clk - an machine class defined object / cookie.
+ * Global clock object, actual structure is declared per-machine
*/
struct clk;
+static inline void clk_common_init(struct clk *clk) { }
+
+/*
+ * For !CONFIG_USE_COMMON_STRUCT_CLK, we don't enforce any atomicity
+ * requirements for clk_enable/clk_disable, so the prepare and unprepare
+ * functions are no-ops
+ */
+static inline int clk_prepare(struct clk *clk) { return 0; }
+static inline void clk_unprepare(struct clk *clk) { }
+
+#endif /* !CONFIG_USE_COMMON_STRUCT_CLK */
+
/**
* clk_get - lookup and obtain a reference to a clock producer.
* @dev: device for clock "consumer"
@@ -67,6 +218,7 @@ void clk_disable(struct clk *clk);
/**
* clk_get_rate - obtain the current clock rate (in Hz) for a clock source.
* This is only valid once the clock source has been enabled.
+ * Returns zero if the clock rate is unknown.
* @clk: clock source
*/
unsigned long clk_get_rate(struct clk *clk);
@@ -83,12 +235,6 @@ unsigned long clk_get_rate(struct clk *clk);
*/
void clk_put(struct clk *clk);
-
-/*
- * The remaining APIs are optional for machine class support.
- */
-
-
/**
* clk_round_rate - adjust a rate to the exact rate a clock can provide
* @clk: clock source
^ permalink raw reply related
* [PATCH 0/2] Common struct clk implementation, v14
From: Jeremy Kerr @ 2011-03-03 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102011711.31258.jeremy.kerr@canonical.com>
Hi all,
These patches are an attempt to allow platforms to share clock code. At
present, the definitions of 'struct clk' are local to platform code,
which makes allocating and initialising cross-platform clock sources
difficult, and makes it impossible to compile a single image containing
support for two ARM platforms with different struct clks.
The three patches are for the architecture-independent kernel code,
introducing the common clk infrastructure. The changelog for the first
patch includes details about the new clock definitions.
Many thanks to the following for their input:
* Benjamin Herrenschmidt <benh@kernel.crashing.org>
* Ben Dooks <ben-linux@fluff.org>
* Baruch Siach <baruch@tkos.co.il>
* Russell King <linux@arm.linux.org.uk>
* Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
* Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
* Vincent Guittot <vincent.guittot@linaro.org>
* Sascha Hauer <s.hauer@pengutronix.de>
* Ryan Mallon <ryan@bluewatersys.com>
* Colin Cross <ccross@google.com>
* Jassi Brar <jassisinghbrar@gmail.com>
* Saravana Kannan <skannan@codeaurora.org>
Cheers,
Jeremy
--
v14:
* make empty clk_prepare & clk_unprepare static inline
v13:
* Don't expose __clk_get and clk_put - prototypes in clkdev.c instead
* Add might_sleep to clk_set_rate
* Comment clarifications & fixups
* Remove zero initialisers
* Fold warnings into main clk.c change
v12:
* Always refcount, even when enable/prepare ops are NULL
* Unify prepare & enable count checking
* Update comments for prepare/unprepare
* Use spin_{lock,unlock}_irqsave
* Change clk_put to __clk_put, and use the shared clk_put
v11:
* add prepare/unprepare for non-atomic switching, document atomicity
* move to drivers/clk/
v10:
* comment fixups, from Uwe's review
* added DEFINE_CLK_FIXED
v9:
* comment improvements
* kerneldoc fixups
* add WARN_ON to clk_disable
v8:
* add atomic clocks, and locking wrappers
* expand comments on clk and clk_ops
v7:
* change CLK_INIT to initialise clk->mutex statically
v6:
* fixed up references to 'clk_operations' in the changelog
v5:
* uninline main API, and share definitions with !USE_COMMON_STRUCT_CLK
* add __clk_get
* delay mutex init
* kerneldoc for struct clk
v4:
* use mutex for enable/disable locking
* DEFINE_CLK -> INIT_CLK, and pass the clk name for mutex init
* struct clk_operations -> struct clk_ops
v3:
* do clock usage refcounting in common code
* provide sample port
v2:
* no longer ARM-specific
* use clk_operations
---
Jeremy Kerr (2):
Add a common struct clk
clk: Generic support for fixed-rate clocks
^ permalink raw reply
* [PATCH 00/17] omap4: pm: suspend, hotplug and cpuilde support
From: Santosh Shilimkar @ 2011-03-03 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87oc5txf0d.fsf@ti.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at ti.com]
> Sent: Thursday, March 03, 2011 5:16 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 00/17] omap4: pm: suspend, hotplug and cpuilde
> support
>
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
> > This series adds OMAP4 suspend and cpuidle support till MPU
> subsystem
> > (MPUSS) off-mode. The suspend on SMP machines uses cpu-hotplug
> > infrastructure to take down the non-boot CPUs. We put secondary
> > CPU(CPU1 in OMAP4) to OFF state via cpu-hotplug.
> > In cpuidle too, low power states are attempted only when the
> > CPU1 is put to OFF state via cpu-hotplug because of hardware
> > constraints.
>
> Minor nit on patch subjects: both OMAP and PM are acronyms, please
> capitalize.
>
Will Fix that.
> Also, can you rebase this on Paul's integration-2.6.39 branch?
> There
> are several things in this series that conflict with changes there.
>
I did that already and found issues around static dependencies.
Rajendra and myself are sorting those out.
Will address the comments on this series and post v2.
Regards,
Santosh
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Add ARMLEX4210 Board support file
From: ALIM AKHTAR @ 2011-03-03 7:27 UTC (permalink / raw)
To: linux-arm-kernel
This patch is based on 'for-next' branch of kgene tree.
This patch adds Samsung ARMLEX4210 board support file
which is based on Exynos4210.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm/mach-exynos4/Kconfig | 13 ++
arch/arm/mach-exynos4/Makefile | 1 +
arch/arm/mach-exynos4/mach-armlex4210.c | 213 +++++++++++++++++++++++++++++++
3 files changed, 227 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-exynos4/mach-armlex4210.c
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index ad03840..a12bddf 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -109,6 +109,19 @@ config MACH_SMDKV310
help
Machine support for Samsung SMDKV310
+config MACH_ARMLEX4210
+ bool "ARMLEX4210"
+ select CPU_EXYNOS4210
+ select S3C_DEV_RTC
+ select S3C_DEV_WDT
+ select S3C_DEV_HSMMC
+ select S3C_DEV_HSMMC2
+ select S3C_DEV_HSMMC3
+ select EXYNOS4_DEV_SYSMMU
+ select EXYNOS4_SETUP_SDHCI
+ help
+ Machine support for Samsung ARMLEX4210 based on EXYNOS4210
+
config MACH_UNIVERSAL_C210
bool "Mobile UNIVERSAL_C210 Board"
select CPU_EXYNOS4210
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 0558235..2860af8 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
obj-$(CONFIG_MACH_SMDKC210) += mach-smdkc210.o
obj-$(CONFIG_MACH_SMDKV310) += mach-smdkv310.o
+obj-$(CONFIG_MACH_ARMLEX4210) += mach-armlex4210.o
obj-$(CONFIG_MACH_UNIVERSAL_C210) += mach-universal_c210.o
# device support
diff --git a/arch/arm/mach-exynos4/mach-armlex4210.c b/arch/arm/mach-exynos4/mach-armlex4210.c
new file mode 100644
index 0000000..856ab6e
--- /dev/null
+++ b/arch/arm/mach-exynos4/mach-armlex4210.c
@@ -0,0 +1,213 @@
+/* linux/arch/arm/mach-exynos4/mach-armlex4210.c
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * 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.
+*/
+
+#include <linux/gpio.h>
+#include <linux/io.h>
+#include <linux/mmc/host.h>
+#include <linux/platform_device.h>
+#include <linux/serial_core.h>
+#include <linux/smsc911x.h>
+
+#include <asm/mach/arch.h>
+#include <asm/mach-types.h>
+
+#include <plat/cpu.h>
+#include <plat/devs.h>
+#include <plat/exynos4.h>
+#include <plat/gpio-cfg.h>
+#include <plat/regs-serial.h>
+#include <plat/regs-srom.h>
+#include <plat/sdhci.h>
+
+#include <mach/map.h>
+
+/* Following are default values for UCON, ULCON and UFCON UART registers */
+#define ARMLEX4210_UCON_DEFAULT (S3C2410_UCON_TXILEVEL | \
+ S3C2410_UCON_RXILEVEL | \
+ S3C2410_UCON_TXIRQMODE | \
+ S3C2410_UCON_RXIRQMODE | \
+ S3C2410_UCON_RXFIFO_TOI | \
+ S3C2443_UCON_RXERR_IRQEN)
+
+#define ARMLEX4210_ULCON_DEFAULT S3C2410_LCON_CS8
+
+#define ARMLEX4210_UFCON_DEFAULT (S3C2410_UFCON_FIFOMODE | \
+ S5PV210_UFCON_TXTRIG4 | \
+ S5PV210_UFCON_RXTRIG4)
+
+static struct s3c2410_uartcfg armlex4210_uartcfgs[] __initdata = {
+ [0] = {
+ .hwport = 0,
+ .flags = 0,
+ .ucon = ARMLEX4210_UCON_DEFAULT,
+ .ulcon = ARMLEX4210_ULCON_DEFAULT,
+ .ufcon = ARMLEX4210_UFCON_DEFAULT,
+ },
+ [1] = {
+ .hwport = 1,
+ .flags = 0,
+ .ucon = ARMLEX4210_UCON_DEFAULT,
+ .ulcon = ARMLEX4210_ULCON_DEFAULT,
+ .ufcon = ARMLEX4210_UFCON_DEFAULT,
+ },
+ [2] = {
+ .hwport = 2,
+ .flags = 0,
+ .ucon = ARMLEX4210_UCON_DEFAULT,
+ .ulcon = ARMLEX4210_ULCON_DEFAULT,
+ .ufcon = ARMLEX4210_UFCON_DEFAULT,
+ },
+ [3] = {
+ .hwport = 3,
+ .flags = 0,
+ .ucon = ARMLEX4210_UCON_DEFAULT,
+ .ulcon = ARMLEX4210_ULCON_DEFAULT,
+ .ufcon = ARMLEX4210_UFCON_DEFAULT,
+ },
+};
+
+static struct s3c_sdhci_platdata armlex4210_hsmmc0_pdata __initdata = {
+ .cd_type = S3C_SDHCI_CD_PERMANENT,
+ .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
+ .max_width = 8,
+ .host_caps = MMC_CAP_8_BIT_DATA,
+#endif
+};
+
+static struct s3c_sdhci_platdata armlex4210_hsmmc2_pdata __initdata = {
+ .cd_type = S3C_SDHCI_CD_GPIO,
+ .ext_cd_gpio = EXYNOS4_GPX2(5),
+ .ext_cd_gpio_invert = 1,
+ .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
+ .max_width = 4,
+};
+
+static struct s3c_sdhci_platdata armlex4210_hsmmc3_pdata __initdata = {
+ .cd_type = S3C_SDHCI_CD_PERMANENT,
+ .max_width = 4,
+};
+
+static void __init armlex4210_sdhci_init(void)
+{
+ s3c_sdhci0_set_platdata(&armlex4210_hsmmc0_pdata);
+ s3c_sdhci2_set_platdata(&armlex4210_hsmmc2_pdata);
+ s3c_sdhci3_set_platdata(&armlex4210_hsmmc3_pdata);
+}
+
+static void __init armlex4210_wlan_init(void)
+{
+ /* enable */
+ s3c_gpio_cfgpin(EXYNOS4_GPX2(0), S3C_GPIO_SFN(0xf));
+ s3c_gpio_setpull(EXYNOS4_GPX2(0), S3C_GPIO_PULL_UP);
+
+ /* reset */
+ s3c_gpio_cfgpin(EXYNOS4_GPX1(6), S3C_GPIO_SFN(0xf));
+ s3c_gpio_setpull(EXYNOS4_GPX1(6), S3C_GPIO_PULL_UP);
+
+ /* wakeup */
+ s3c_gpio_cfgpin(EXYNOS4_GPX1(5), S3C_GPIO_SFN(0xf));
+ s3c_gpio_setpull(EXYNOS4_GPX1(5), S3C_GPIO_PULL_UP);
+}
+
+static struct resource armlex4210_smsc911x_resources[] = {
+ [0] = {
+ .start = EXYNOS4_PA_SROM_BANK(3),
+ .end = EXYNOS4_PA_SROM_BANK(3) + SZ_64K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_EINT(27),
+ .end = IRQ_EINT(27),
+ .flags = IORESOURCE_IRQ | IRQF_TRIGGER_HIGH,
+ },
+};
+
+static struct smsc911x_platform_config smsc9215_config = {
+ .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH,
+ .irq_type = SMSC911X_IRQ_TYPE_PUSH_PULL,
+ .flags = SMSC911X_USE_16BIT | SMSC911X_FORCE_INTERNAL_PHY,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+ .mac = {0x00, 0x80, 0x00, 0x23, 0x45, 0x67},
+};
+
+static struct platform_device armlex4210_smsc911x = {
+ .name = "smsc911x",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(armlex4210_smsc911x_resources),
+ .resource = armlex4210_smsc911x_resources,
+ .dev = {
+ .platform_data = &smsc9215_config,
+ },
+};
+
+static struct platform_device *armlex4210_devices[] __initdata = {
+ &s3c_device_hsmmc0,
+ &s3c_device_hsmmc2,
+ &s3c_device_hsmmc3,
+ &s3c_device_rtc,
+ &s3c_device_wdt,
+ &exynos4_device_sysmmu,
+ &samsung_asoc_dma,
+ &armlex4210_smsc911x,
+};
+
+static void __init armlex4210_smsc911x_init(void)
+{
+ u32 cs1;
+
+ /* configure nCS1 width to 16 bits */
+ cs1 = __raw_readl(S5P_SROM_BW) &
+ ~(S5P_SROM_BW__CS_MASK << S5P_SROM_BW__NCS1__SHIFT);
+ cs1 |= ((1 << S5P_SROM_BW__DATAWIDTH__SHIFT) |
+ (0 << S5P_SROM_BW__WAITENABLE__SHIFT) |
+ (1 << S5P_SROM_BW__ADDRMODE__SHIFT) |
+ (1 << S5P_SROM_BW__BYTEENABLE__SHIFT)) <<
+ S5P_SROM_BW__NCS1__SHIFT;
+ __raw_writel(cs1, S5P_SROM_BW);
+
+ /* set timing for nCS1 suitable for ethernet chip */
+ __raw_writel((0x1 << S5P_SROM_BCX__PMC__SHIFT) |
+ (0x9 << S5P_SROM_BCX__TACP__SHIFT) |
+ (0xc << S5P_SROM_BCX__TCAH__SHIFT) |
+ (0x1 << S5P_SROM_BCX__TCOH__SHIFT) |
+ (0x6 << S5P_SROM_BCX__TACC__SHIFT) |
+ (0x1 << S5P_SROM_BCX__TCOS__SHIFT) |
+ (0x1 << S5P_SROM_BCX__TACS__SHIFT), S5P_SROM_BC1);
+}
+
+static void __init armlex4210_map_io(void)
+{
+ s5p_init_io(NULL, 0, S5P_VA_CHIPID);
+ s3c24xx_init_clocks(24000000);
+ s3c24xx_init_uarts(armlex4210_uartcfgs,
+ ARRAY_SIZE(armlex4210_uartcfgs));
+}
+
+static void __init armlex4210_machine_init(void)
+{
+ armlex4210_smsc911x_init();
+
+ armlex4210_sdhci_init();
+
+ armlex4210_wlan_init();
+
+ platform_add_devices(armlex4210_devices,
+ ARRAY_SIZE(armlex4210_devices));
+}
+
+MACHINE_START(ARMLEX4210, "ARMLEX4210")
+ /* Maintainer: Alim Akhtar <alim.akhtar@samsung.com> */
+ .boot_params = S5P_PA_SDRAM + 0x100,
+ .init_irq = exynos4_init_irq,
+ .map_io = armlex4210_map_io,
+ .init_machine = armlex4210_machine_init,
+ .timer = &exynos4_timer,
+MACHINE_END
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ARM: S5P: Add platform helpers for camera GPIO configuration
From: Kukjin Kim @ 2011-03-03 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D67AB20.8000000@samsung.com>
Sylwester Nawrocki wrote:
>
>
> On 02/11/2011 07:07 PM, Sylwester Nawrocki wrote:
> > Add functions for the parallel camera GPIO interface
> > configuration on S5PV210 and S5PV310 SoCs.
> >
>
> Kukjin, are you OK with general concept of those?
> I would probably need to rework the patches after recent
> S5PV310 -> EXYNOS4 renaming. And move camera.h
> to arch/arm/plat-samsung/include/plat/?
>
> What's your opinion?
Oh, missed...yeah need to re-work based on exynos4 :)
And you don't need to move it into plat-samsung/ because plat-s5p/ is used
for Exynos also.
Please refer to my comments on it.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH] ARM: S5P: Add platform helpers for camera GPIO configuration
From: Kukjin Kim @ 2011-03-03 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297447665-19492-2-git-send-email-s.nawrocki@samsung.com>
Sylwester Nawrocki wrote:
>
> Add functions for the parallel camera GPIO interface
> configuration on S5PV210 and S5PV310 SoCs.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Signed-off-by: Kyungmin Park <s.nawrocki@samsung.com>
Hmm...typo?
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
> arch/arm/mach-s5pv210/Kconfig | 5 +++
> arch/arm/mach-s5pv210/Makefile | 1 +
> arch/arm/mach-s5pv210/setup-camera.c | 53
> +++++++++++++++++++++++++++++++
> arch/arm/mach-s5pv310/Kconfig | 5 +++
> arch/arm/mach-s5pv310/Makefile | 1 +
> arch/arm/mach-s5pv310/setup-camera.c | 43 +++++++++++++++++++++++++
> arch/arm/plat-s5p/include/plat/camera.h | 26 +++++++++++++++
> 7 files changed, 134 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5pv210/setup-camera.c
> create mode 100644 arch/arm/mach-s5pv310/setup-camera.c
> create mode 100644 arch/arm/plat-s5p/include/plat/camera.h
>
> diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
> index 53aabef..300993a 100644
> --- a/arch/arm/mach-s5pv210/Kconfig
> +++ b/arch/arm/mach-s5pv210/Kconfig
> @@ -53,6 +53,11 @@ config S5PV210_SETUP_SDHCI_GPIO
> help
> Common setup code for SDHCI gpio.
>
> +config S5PV210_SETUP_CAMERA
How about "S5PV210_SETUP_FIMC"?
As you know, it belong to FIMC block which is written in datasheet.
And this naming is more reasonable like SETUP_I2C...
> + bool
> + help
> + Common setup code for the camera interfaces.
> +
> menu "S5PC110 Machines"
>
> config MACH_AQUILA
> diff --git a/arch/arm/mach-s5pv210/Makefile
b/arch/arm/mach-s5pv210/Makefile
> index ff1a0db..d6c9f0d 100644
> --- a/arch/arm/mach-s5pv210/Makefile
> +++ b/arch/arm/mach-s5pv210/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_MACH_TORBRECK) += mach-torbreck.o
> obj-y += dev-audio.o
> obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
>
> +obj-$(CONFIG_S5PV210_SETUP_CAMERA) += setup-camera.o
> obj-$(CONFIG_S5PV210_SETUP_FB_24BPP) += setup-fb-24bpp.o
> obj-$(CONFIG_S5PV210_SETUP_I2C1) += setup-i2c1.o
> obj-$(CONFIG_S5PV210_SETUP_I2C2) += setup-i2c2.o
> diff --git a/arch/arm/mach-s5pv210/setup-camera.c b/arch/arm/mach-
> s5pv210/setup-camera.c
> new file mode 100644
> index 0000000..e13c354
> --- /dev/null
> +++ b/arch/arm/mach-s5pv210/setup-camera.c
So setup-fimc.c
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2011 Samsung Electronics Co., Ltd.
> + *
> + * S5PV310 camera interface GPIO configuration.
> + *
> + * 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.
> + */
> +
> +#include <linux/gpio.h>
> +#include <plat/gpio-cfg.h>
> +#include <plat/camera.h>
> +
> +/*
> + * Configure the camera parallel bus pins. The parallel bus can be
> multiplexed
> + * with any FIMC entity. Even multiple FIMC entities are allowed to be
> attached
> + * to a particular (A or B) gpio interface. This function should be
called
> from
> + * a board setup code.
> + */
> +int s5pv210_camif_cfg_gpio(enum s5p_camif_id id)
int s5pv210_fimc_cfg_gpio...
> +{
> + u32 gpio8, gpio5;
> + int ret;
> + int i = 5;
> +
> + switch (id) {
> + case S5P_CAMIF_A:
> + gpio8 = S5PV210_GPE0(0);
> + gpio5 = S5PV210_GPE1(0);
> + break;
Blank line?
> + case S5P_CAMIF_B:
> + gpio8 = S5PV210_GPJ0(0);
> + gpio5 = S5PV210_GPJ1(0);
> + break;
Same...
> + default:
> + WARN(1, "id: %d\n", id);
> + return -EINVAL;
> + }
> +
> + ret = s3c_gpio_cfgall_range(gpio8, 8, S3C_GPIO_SFN(2),
> + S3C_GPIO_PULL_UP);
> + if (ret)
> + return ret;
> +
> + ret = s3c_gpio_cfgall_range(gpio5, 5, S3C_GPIO_SFN(2),
> + S3C_GPIO_PULL_UP);
Where is "return ret;" ?
> +
> + while (i-- && !ret)
> + ret = s5p_gpio_set_drvstr(S5PV210_GPE1(i),
> + S5P_GPIO_DRVSTR_LV4);
Basically drive strength depends on each board. So I think, should be
removed here.
> + return ret;
> +}
> diff --git a/arch/arm/mach-s5pv310/Kconfig b/arch/arm/mach-s5pv310/Kconfig
> index b2a9acc..ccd1dc4 100644
> --- a/arch/arm/mach-s5pv310/Kconfig
> +++ b/arch/arm/mach-s5pv310/Kconfig
> @@ -71,6 +71,11 @@ config S5PV310_DEV_SYSMMU
> help
> Common setup code for SYSTEM MMU in S5PV310
>
> +config S5PV310_SETUP_CAMERA
S5PV310_SETUP_FIMC ?
> + bool
> + help
> + Common setup code for the camera interfaces.
> +
> # machine support
>
> menu "S5PC210 Machines"
> diff --git a/arch/arm/mach-s5pv310/Makefile
b/arch/arm/mach-s5pv310/Makefile
> index 036fb38..c1d6577 100644
> --- a/arch/arm/mach-s5pv310/Makefile
> +++ b/arch/arm/mach-s5pv310/Makefile
> @@ -32,6 +32,7 @@ obj-y +=
dev-audio.o
> obj-$(CONFIG_S5PV310_DEV_PD) += dev-pd.o
> obj-$(CONFIG_S5PV310_DEV_SYSMMU) += dev-sysmmu.o
>
> +obj-$(CONFIG_S5PV310_SETUP_CAMERA) += setup-camera.o
> obj-$(CONFIG_S5PV310_SETUP_I2C1) += setup-i2c1.o
> obj-$(CONFIG_S5PV310_SETUP_I2C2) += setup-i2c2.o
> obj-$(CONFIG_S5PV310_SETUP_I2C3) += setup-i2c3.o
> diff --git a/arch/arm/mach-s5pv310/setup-camera.c b/arch/arm/mach-
> s5pv310/setup-camera.c
> new file mode 100644
> index 0000000..8ab239e
> --- /dev/null
> +++ b/arch/arm/mach-s5pv310/setup-camera.c
Almost same.
(snip)
> diff --git a/arch/arm/plat-s5p/include/plat/camera.h b/arch/arm/plat-
> s5p/include/plat/camera.h
> new file mode 100644
> index 0000000..f7c66ec
> --- /dev/null
> +++ b/arch/arm/plat-s5p/include/plat/camera.h
How about camport.h?
> @@ -0,0 +1,26 @@
> +/*
> + * Copyright (C) 2011 Samsung Electronics Co., Ltd.
> + *
> + * S5P series camera interface helper functions
> + *
> + * 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.
> + */
> +
> +#ifndef PLAT_S5P_CAMERA_H_
> +#define PLAT_S5P_CAMERA_H_ __FILE__
> +
> +enum s5p_camif_id {
> + S5P_CAMIF_A,
> + S5P_CAMIF_B,
> +};
Because I think, "CAMPORT" is more clearly.
enum s5p_camport_id {
S5P_CAMPORT_A,
S5P_CAMPORT_B,
};
> +
> +/**
> + * s5pvX10_camif_cfg_gpio - configure IO pins of the camera A/B interface
> + * @id: id of a camera gpio interface
> + */
> +int s5pv210_camif_cfg_gpio(enum s5p_camif_id id);
> +int s5pv310_camif_cfg_gpio(enum s5p_camif_id id);
> +
> +#endif /* PLAT_S5P_CAMERA_H_ */
> --
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 1/1] CPU Frequency Scaling for VT8500/WM8505
From: Tony Prisk @ 2011-03-03 7:46 UTC (permalink / raw)
To: linux-arm-kernel
Add CPU Frequency Scaling support for VT8500/WM8505 based system.
Signed-off-by: Tony Prisk (linux at prisktech.co.nz)
diff --git a/arch/arm/mach-vt8500/Makefile b/arch/arm/mach-vt8500/Makefile
index 7422e8a..e1df248 100644
--- a/arch/arm/mach-vt8500/Makefile
+++ b/arch/arm/mach-vt8500/Makefile
@@ -7,3 +7,7 @@ obj-$(CONFIG_MACH_BV07) += bv07.o
obj-$(CONFIG_MACH_WM8505_7IN_NETBOOK) += wm8505_7in.o
obj-$(CONFIG_HAVE_PWM) += pwm.o
+
+ifeq ($(CONFIG_CPU_FREQ), y)
+ obj-y += cpufreq.o
+endif
diff --git a/arch/arm/mach-vt8500/cpufreq.c b/arch/arm/mach-vt8500/cpufreq.c
new file mode 100644
index 0000000..570d9e8
--- /dev/null
+++ b/arch/arm/mach-vt8500/cpufreq.c
@@ -0,0 +1,209 @@
+/*
+ * linux/arch/arm/mach-vt8500/cpufreq.c
+ *
+ * CPU frequency scaling
+ * Copyright (c) 2008 Wondermedia Technologies, Inc.
+ * Copyright (c) 2011 Tony Prisk.
+ *
+ * This program is free software: you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation, either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have recieved a copy of the GNU PUblic License along with this
+ * program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * WonderMedia Technologies, Inc.
+ * 10F, 529, Chung-Cheng Road, Hsin-Tien, Taipei 231, R.O.C.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/cpufreq.h>
+#include <linux/io.h>
+#include <linux/delay.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+
+#include <mach/wm8505_regs.h>
+
+#define wmt_cpufreq_read_reg(reg) readl(pmc_base + reg)
+#define wmt_cpufreq_write_reg(reg, val) writel(val, pmc_base + reg)
+
+struct wmt_freq_t {
+ u32 cpu_khz;
+ u32 pll_a;
+ u32 ahb;
+};
+
+static struct wmt_freq_t wmt_freqs[] = {
+ { 50000, 100000000, 50000000 },
+ { 75000, 150000000, 75000000 },
+ { 100000, 200000000, 100000000 },
+ { 125000, 250000000, 62500000 },
+ { 150000, 300000000, 75000000 },
+ { 175000, 350000000, 87500000 },
+ { 200000, 400000000, 100000000 },
+ { 225000, 450000000, 112500000 },
+ { 250000, 500000000, 125000000 },
+ { 275000, 550000000, 137500000 },
+ { 300000, 600000000, 150000000 },
+ { 325000, 650000000, 162500000 },
+ { 350000, 700000000, 175000000 },
+ { 375000, 750000000, 125000000 },
+ { 387500, 775000000, 129166666 },
+};
+
+#define WMT_NUM_FREQS ARRAY_SIZE(wmt_freqs)
+
+struct clk *cpufreq_clk_arm;
+struct clk *cpufreq_clk_ahb;
+
+static u32 wmt_freq_to_idx(u32 khz)
+{
+ int idx;
+
+ for (idx = 0; idx < WMT_NUM_FREQS; idx++)
+ if (wmt_freqs[idx].cpu_khz >= khz)
+ return idx;
+
+ return WMT_NUM_FREQS - 1;
+}
+
+static u32 wmt_idx_to_freq(u32 idx)
+{
+ if (idx < WMT_NUM_FREQS)
+ return wmt_freqs[idx].cpu_khz;
+ else
+ return wmt_freqs[WMT_NUM_FREQS - 1].cpu_khz;
+}
+
+static struct wmt_freq_t *wmt_idx_to_params(u32 idx)
+{
+ if (idx < WMT_NUM_FREQS)
+ return &wmt_freqs[idx];
+ else
+ return &wmt_freqs[WMT_NUM_FREQS - 1];
+}
+
+static unsigned int wmt_cpufreq_get_current(void)
+{
+ return (u32)(clk_get_rate(cpufreq_clk_arm) / 1000);
+}
+
+static unsigned int wmt_cpufreq_get(unsigned int cpu)
+{
+ return wmt_cpufreq_get_current();
+}
+
+static int wmt_cpufreq_verify(struct cpufreq_policy *policy)
+{
+ u32 tmp;
+ if (policy->cpu != 0)
+ return -EINVAL;
+
+ cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq, \
+ policy->cpuinfo.max_freq);
+
+ tmp = wmt_freqs[wmt_freq_to_idx(policy->min)].cpu_khz;
+
+ if (tmp > policy->max)
+ policy->max = tmp;
+
+ cpufreq_verify_within_limits(policy, policy->cpuinfo.min_freq, \
+ policy->cpuinfo.max_freq);
+
+ return 0;
+}
+
+static void wmt_speedstep(unsigned int idx)
+{
+ struct wmt_freq_t *np;
+ np = wmt_idx_to_params(idx);
+
+ clk_set_rate(cpufreq_clk_arm, np->cpu_khz * 1000);
+ clk_set_rate(cpufreq_clk_ahb, np->ahb);
+}
+
+static int wmt_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int target_freq,
+ unsigned int relation)
+{
+ unsigned int idx;
+ unsigned long flags;
+ struct cpufreq_freqs freqs;
+
+ idx = wmt_freq_to_idx(target_freq);
+
+ switch (relation) {
+ case CPUFREQ_RELATION_L:
+ if (wmt_idx_to_freq(idx) > policy->max)
+ idx--;
+ break;
+ case CPUFREQ_RELATION_H:
+ if ((wmt_idx_to_freq(idx) > target_freq) &&
+ (wmt_idx_to_freq(idx-1) >= policy->min))
+ idx--;
+ break;
+ }
+
+ freqs.old = wmt_cpufreq_get_current();
+ freqs.new = wmt_idx_to_freq(idx);
+ freqs.cpu = 0;
+
+ if (freqs.new != freqs.old) {
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ local_irq_save(flags);
+ wmt_speedstep(idx);
+ local_irq_restore(flags);
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+ }
+
+ return 0;
+}
+
+static int wmt_cpufreq_init(struct cpufreq_policy *policy)
+{
+ if (policy->cpu != 0)
+ return -EINVAL;
+
+ cpufreq_clk_arm = clk_get(NULL, "arm");
+ if (IS_ERR(cpufreq_clk_arm))
+ return PTR_ERR(cpufreq_clk_arm);
+ cpufreq_clk_ahb = clk_get(NULL, "ahb");
+ if (IS_ERR(cpufreq_clk_ahb))
+ return PTR_ERR(cpufreq_clk_ahb);
+
+ policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
+ policy->cpuinfo.min_freq = wmt_freqs[0].cpu_khz;
+ policy->cpuinfo.max_freq = wmt_freqs[WMT_NUM_FREQS - 1].cpu_khz;
+ policy->cpuinfo.transition_latency = 1000000; /* 1ms, assumed? */
+ policy->cur = wmt_cpufreq_get_current();
+ policy->min = 100000;
+ policy->max = 350000;
+
+ return 0;
+}
+
+static struct cpufreq_driver wmt_cpufreq_driver = {
+ .flags = CPUFREQ_STICKY,
+ .init = wmt_cpufreq_init,
+ .verify = wmt_cpufreq_verify,
+ .target = wmt_cpufreq_target,
+ .get = wmt_cpufreq_get,
+ .name = "wmt",
+};
+
+static int __init wmt_cpuf_init(void)
+{
+ return cpufreq_register_driver(&wmt_cpufreq_driver);
+}
+
+arch_initcall(wmt_cpuf_init);
^ permalink raw reply related
* CONFIG_ARM_DMA_MEM_BUFFERABLE and readl/writel weirdness
From: Saravana Kannan @ 2011-03-03 7:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302083904.GA4493@n2100.arm.linux.org.uk>
Sorry that it took a while for me to get back. Had to contact our
resident ARM expert to reconfirm my points and gather all the data in an
externally available format.
On 03/02/2011 12:39 AM, Russell King - ARM Linux wrote:
> On Tue, Mar 01, 2011 at 05:23:15PM -0800, Saravana Kannan wrote:
>> If I'm not missing some magic, this would mean that
>> "CONFIG_ARM_DMA_MEM_BUFFERABLE" determines if readl(s)/writel(s) get to
>> have a built in mb() or not.
>
> You're missing that CONFIG_ARM_DMA_MEM_BUFFERABLE not only changes
> readl/writel but also the type for DMA coherent memory from strongly
> ordered to memory, non-cacheable.
Yeah, I noticed that after I sent the email, but my questions in my
previous email still remains valid. See below.
> The barriers are required to ensure that reads and writes to DMA
> coherent memory are visible to the DMA device before the write
> completes, and any value read from DMA coherent memory will not
> bypass a read from a DMA device.
>
> The barriers in the IO macros have nothing to do with whether reads/writes
> to normal cacheable memory are visible to DMA devices. That is what the
> streaming DMA API is for.
>
> In any case, the IO macros are always ordered with respect to other
> device writes irrespective of CONFIG_ARM_DMA_MEM_BUFFERABLE.
<snip>
> I think you misunderstand what's going on. IO accesses are always ordered
> with respect to themselves. The barriers are there to ensure ordering
> between DMA coherent memory (normal non-cached memory) and IO accesses
> (device).
Unfortunately this is not correct. The ARM spec doesn't guarantee that
all IO accesses should be ordered with respect to themselves. It only
requires that the ordering should be guaranteed at least within a 1KB
region.
You can find this info in ARMv7 ARM spec[1] named
"DDI0406B_arm_architecture_reference_manual_errata_markup_8_0.pdf", on
page A3-45. There is a para that goes:
"Accesses must arrive at any particular memory-mapped peripheral or
block of memory in program order, that is, A1 must arrive before A2.
There are no ordering restrictions about when accesses arrive at
different peripherals or blocks of memory, provided that the accesses
follow the general ordering rules given in this section."
And the most critical point is hidden in a comment that goes:
"The size of a memory mapped peripheral, or a block of memory, is
IMPLEMENTATION DEFINED, but is not smaller than 1KByte."
I guess most of the confusion is due to the ARM spec not being very
obvious about the 1KB limitation.
So, going back to my point, I think it's wrong for
CONFIG_ARM_DMA_MEM_BUFFERABLE to control how stuff unrelated to DMA behaves.
I have also encountered a few people who kept went "but readl/writel was
recently changed to add mem barriers, so we can all remove the mb()s in
our driver (unrelated to DMA) code". That would have made their code
incorrect for two reasons:
1. readl/writel doesn't always have a mem barrier because of config that
can be turned off.
2. In cases where readl/writel didn't have mb(), there is not enough
ordering guarantee without an explicit mb().
I think as a community, we should stop saying that readl/writel ensures
ordering with respect to all IO accesses. It doesn't even guarantee
ordering within the same device (when their register regions are > 1KB).
After reading the above, please let me know if a patch to decouple the
"readl/writel with builtin mb()" from CONFIG_ARM_DMA_MEM_BUFFERABLE
would be accepted. If so, I can go ahead and send it out soon.
[1]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0406b/index.html
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* CONFIG_ARM_DMA_MEM_BUFFERABLE and readl/writel weirdness
From: Saravana Kannan @ 2011-03-03 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201103020923.36796.arnd@arndb.de>
On 03/02/2011 12:23 AM, Arnd Bergmann wrote:
> On Wednesday 02 March 2011 02:23:15 Saravana Kannan wrote:
>> There are so many other drivers that don't use or care about DMA and
>> might still want to ensure some ordering constraints between their
>> readl(s)/writel(s). They can't depend on readl/writel taking care of it
>> for them since their code could be used in a kernel configuration that
>> doesn't enable this config.
>
> What exactly are the ordering constraints, do you need the full
> dmb() for readl() and dsb() for writel(), or just a compiler barrier?
I wasn't referring to a compiler barrier. I'm referring to one of the
real barrier instructions.
> I think we need the barrier() even for the relaxed variant, but
> that is fairly lightweight. What would be a reason to have more?
Please see my response to Russell in other other email. I think it
should answer your question by clarifying my point.
>> Firstly, I don't know how many people noticed this and realize they
>> can't depend on readl/writel to take care of the mb()s for them. Seems
>> like an unnecessary encouragement to make mistakes when it didn't need
>> to be so.
>>
>> Secondly, even if they realize they have to take care of it, they will
>> have to continue using mb()s in to force ordering between their
>> reads/writes. So, are we depending on the compiler to optimize these
>> extra mb() out in the case where the config is enabled? I'm not sure it
>> will be able to optimize out the extra mb()s in all cases.
>
> The compiler certainly won't merge multiple inline assembly statements,
> but multiple barrier() statements don't make it worse than just one.
> barrier() just forces accessing variables from memory that could otherwise
> be kept in registers.
Yes, I was aware of how compiler barriers work and how multiple
consecutive compiler barriers are the same as one compiler barrier. The
email was about the real barrier instructions.
> The other problems we still need to fix are the complete absence of
> barriers in inb()/outb() style accessors, which are meant to be stricter
> than readl()/writel(), and the fact that we rely on undefined behavior
> in gcc regarding the atomicity of multi-byte accesses, as we recently
> found out when a new gcc turned a readl into byte accesses.
I haven't gotten that far :-) I really appreciate response!
Thanks,
Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] ARM: mx51: Print silicon revision on boot
From: Arnaud Patard (Rtp) @ 2011-03-03 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299114747-14091-1-git-send-email-festevam@gmail.com>
Fabio Estevam <festevam@gmail.com> writes:
Hi,
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Why I like having boot log, I don't like have too verbose boot logs. If
you add this, you have a good reason (I hope), but I can't know
it. There's no patch description. So, please give a patch with proper
explanation of why you need that. Anyway, having a proper patch
description is imho always a good idea.
Moreover, there's already good hint if you want to know if you're on to2
or to3. On rev < 3.0, you have this in logs:
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 2
Turning off NEON support, detected broken NEON implementation
Arnaud
^ permalink raw reply
* [PATCH 1/2] ARM: imx5x: clean up ARCH_MX5X
From: Richard Zhao @ 2011-03-03 8:40 UTC (permalink / raw)
To: linux-arm-kernel
Move to SOC_SOC_IMX5X. Leave only places which prevent multi-soc
using ARCH_MX5X.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 03ec6e9..83ee088 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -1,5 +1,6 @@
if ARCH_MX5
-# ARCH_MX51 and ARCH_MX50 are left for compatibility
+# ARCH_MX50/51/53 are left to mark places where prevent multi-soc in single
+# image. So for most time, SOC_IMX50/51/53 should be used.
config ARCH_MX50
bool
diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index 33530d2..be7df13 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -194,7 +194,7 @@ static int __init imxXX_add_imx_dma(void)
} else
#endif
-#if defined(CONFIG_ARCH_MX51)
+#if defined(CONFIG_SOC_IMX51)
if (cpu_is_mx51()) {
imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51_to1;
ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
diff --git a/arch/arm/plat-mxc/include/mach/irqs.h b/arch/arm/plat-mxc/include/mach/irqs.h
index ba65c92..a3d930d 100644
--- a/arch/arm/plat-mxc/include/mach/irqs.h
+++ b/arch/arm/plat-mxc/include/mach/irqs.h
@@ -23,17 +23,17 @@
#define MXC_GPIO_IRQ_START MXC_INTERNAL_IRQS
/* these are ordered by size to support multi-SoC kernels */
-#if defined CONFIG_ARCH_MX53
+#if defined CONFIG_SOC_IMX53
#define MXC_GPIO_IRQS (32 * 7)
#elif defined CONFIG_ARCH_MX2
#define MXC_GPIO_IRQS (32 * 6)
-#elif defined CONFIG_ARCH_MX50
+#elif defined CONFIG_SOC_IMX50
#define MXC_GPIO_IRQS (32 * 6)
#elif defined CONFIG_ARCH_MX1
#define MXC_GPIO_IRQS (32 * 4)
#elif defined CONFIG_ARCH_MX25
#define MXC_GPIO_IRQS (32 * 4)
-#elif defined CONFIG_ARCH_MX51
+#elif defined CONFIG_SOC_IMX51
#define MXC_GPIO_IRQS (32 * 4)
#elif defined CONFIG_ARCH_MXC91231
#define MXC_GPIO_IRQS (32 * 4)
diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
index 04c7a26..3781f2f 100644
--- a/arch/arm/plat-mxc/include/mach/mxc.h
+++ b/arch/arm/plat-mxc/include/mach/mxc.h
@@ -127,7 +127,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx35() (0)
#endif
-#ifdef CONFIG_ARCH_MX50
+#ifdef CONFIG_SOC_IMX50
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
@@ -139,7 +139,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx50() (0)
#endif
-#ifdef CONFIG_ARCH_MX51
+#ifdef CONFIG_SOC_IMX51
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
@@ -151,7 +151,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx51() (0)
#endif
-#ifdef CONFIG_ARCH_MX53
+#ifdef CONFIG_SOC_IMX53
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index c895922..450afc5 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -476,7 +476,7 @@ config MTD_NAND_MPC5121_NFC
config MTD_NAND_MXC
tristate "MXC NAND support"
- depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || ARCH_MX51
+ depends on IMX_HAVE_PLATFORM_MXC_NAND
help
This enables the driver for the NAND flash controller on the
MXC processors.
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index bb233a9..9f9d3f7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -164,10 +164,10 @@ config SPI_IMX_VER_0_4
def_bool y if ARCH_MX31
config SPI_IMX_VER_0_7
- def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
+ def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
config SPI_IMX_VER_2_3
- def_bool y if ARCH_MX51 || ARCH_MX53
+ def_bool y if SOC_IMX51 || SOC_IMX53
config SPI_IMX
tristate "Freescale i.MX SPI controllers"
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] ARM: imx3x: clean up ARCH_MX3X
From: Richard Zhao @ 2011-03-03 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299141603-22148-1-git-send-email-richard.zhao@freescale.com>
Move to SOC_SOC_IMX3X.
Leave ARCH_MX31/35 definitions there, in case some place prevent multi-soc
single image.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index e4509ba..2bd4ccf 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -811,7 +811,7 @@ config CACHE_FEROCEON_L2_WRITETHROUGH
config CACHE_L2X0
bool "Enable the L2x0 outer cache controller"
depends on REALVIEW_EB_ARM11MP || MACH_REALVIEW_PB11MP || MACH_REALVIEW_PB1176 || \
- REALVIEW_EB_A9MP || ARCH_MX35 || ARCH_MX31 || MACH_REALVIEW_PBX || \
+ REALVIEW_EB_A9MP || SOC_IMX35 || SOC_IMX31 || MACH_REALVIEW_PBX || \
ARCH_NOMADIK || ARCH_OMAP4 || ARCH_S5PV310 || ARCH_TEGRA || \
ARCH_U8500 || ARCH_VEXPRESS_CA9X4 || ARCH_SHMOBILE
default y
diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index be7df13..3538b85 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -94,7 +94,7 @@ static struct sdma_script_start_addrs addr_imx25_to1 = {
};
#endif
-#ifdef CONFIG_ARCH_MX31
+#ifdef CONFIG_SOC_IMX31
static struct sdma_script_start_addrs addr_imx31_to1 = {
.per_2_per_addr = 1677,
};
@@ -106,7 +106,7 @@ static struct sdma_script_start_addrs addr_imx31_to2 = {
};
#endif
-#ifdef CONFIG_ARCH_MX35
+#ifdef CONFIG_SOC_IMX35
static struct sdma_script_start_addrs addr_imx35_to1 = {
.ap_2_ap_addr = 642,
.uart_2_mcu_addr = 817,
diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
index 3781f2f..7e07263 100644
--- a/arch/arm/plat-mxc/include/mach/mxc.h
+++ b/arch/arm/plat-mxc/include/mach/mxc.h
@@ -103,7 +103,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx27() (0)
#endif
-#ifdef CONFIG_ARCH_MX31
+#ifdef CONFIG_SOC_IMX31
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
@@ -115,7 +115,7 @@ extern unsigned int __mxc_cpu_type;
# define cpu_is_mx31() (0)
#endif
-#ifdef CONFIG_ARCH_MX35
+#ifdef CONFIG_SOC_IMX35
# ifdef mxc_cpu_type
# undef mxc_cpu_type
# define mxc_cpu_type __mxc_cpu_type
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0382332..9928115 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1944,7 +1944,7 @@ config 68360_ENET
config FEC
bool "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on M523x || M527x || M5272 || M528x || M520x || M532x || \
- MACH_MX27 || ARCH_MX35 || ARCH_MX25 || ARCH_MX5 || SOC_IMX28
+ IMX_HAVE_PLATFORM_FEC || SOC_IMX28
select PHYLIB
help
Say Y here if you want to use the built-in 10/100 Fast ethernet
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9f9d3f7..bd9dad5 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -161,10 +161,10 @@ config SPI_IMX_VER_0_0
def_bool y if SOC_IMX21 || SOC_IMX27
config SPI_IMX_VER_0_4
- def_bool y if ARCH_MX31
+ def_bool y if SOC_MX31
config SPI_IMX_VER_0_7
- def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
+ def_bool y if ARCH_MX25 || SOC_IMX35 || SOC_IMX51 || SOC_IMX53
config SPI_IMX_VER_2_3
def_bool y if SOC_IMX51 || SOC_IMX53
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index 77b1eb5..834fe94 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -88,7 +88,7 @@ eenahb:
void fsl_udc_clk_finalize(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
-#if defined(CONFIG_ARCH_MX35)
+#if defined(CONFIG_SOC_IMX35)
unsigned int v;
/* workaround ENGcm09152 for i.MX35 */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] ARM: imx5x: clean up ARCH_MX5X
From: Uwe Kleine-König @ 2011-03-03 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299141603-22148-1-git-send-email-richard.zhao@freescale.com>
On Thu, Mar 03, 2011 at 04:40:02PM +0800, Richard Zhao wrote:
> Move to SOC_SOC_IMX5X. Leave only places which prevent multi-soc
> using ARCH_MX5X.
>
> Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
Looks OK, probably you need to split off the changes that touch files in
drivers/ though.
(Hmm, no diffstat?)
Best regards
Uwe
> diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> index 03ec6e9..83ee088 100644
> --- a/arch/arm/mach-mx5/Kconfig
> +++ b/arch/arm/mach-mx5/Kconfig
> @@ -1,5 +1,6 @@
> if ARCH_MX5
> -# ARCH_MX51 and ARCH_MX50 are left for compatibility
> +# ARCH_MX50/51/53 are left to mark places where prevent multi-soc in single
> +# image. So for most time, SOC_IMX50/51/53 should be used.
>
> config ARCH_MX50
> bool
> diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> index 33530d2..be7df13 100644
> --- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
> +++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> @@ -194,7 +194,7 @@ static int __init imxXX_add_imx_dma(void)
> } else
> #endif
>
> -#if defined(CONFIG_ARCH_MX51)
> +#if defined(CONFIG_SOC_IMX51)
> if (cpu_is_mx51()) {
> imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51_to1;
> ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
> diff --git a/arch/arm/plat-mxc/include/mach/irqs.h b/arch/arm/plat-mxc/include/mach/irqs.h
> index ba65c92..a3d930d 100644
> --- a/arch/arm/plat-mxc/include/mach/irqs.h
> +++ b/arch/arm/plat-mxc/include/mach/irqs.h
> @@ -23,17 +23,17 @@
> #define MXC_GPIO_IRQ_START MXC_INTERNAL_IRQS
>
> /* these are ordered by size to support multi-SoC kernels */
> -#if defined CONFIG_ARCH_MX53
> +#if defined CONFIG_SOC_IMX53
> #define MXC_GPIO_IRQS (32 * 7)
> #elif defined CONFIG_ARCH_MX2
> #define MXC_GPIO_IRQS (32 * 6)
> -#elif defined CONFIG_ARCH_MX50
> +#elif defined CONFIG_SOC_IMX50
> #define MXC_GPIO_IRQS (32 * 6)
> #elif defined CONFIG_ARCH_MX1
> #define MXC_GPIO_IRQS (32 * 4)
> #elif defined CONFIG_ARCH_MX25
> #define MXC_GPIO_IRQS (32 * 4)
> -#elif defined CONFIG_ARCH_MX51
> +#elif defined CONFIG_SOC_IMX51
> #define MXC_GPIO_IRQS (32 * 4)
> #elif defined CONFIG_ARCH_MXC91231
> #define MXC_GPIO_IRQS (32 * 4)
> diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
> index 04c7a26..3781f2f 100644
> --- a/arch/arm/plat-mxc/include/mach/mxc.h
> +++ b/arch/arm/plat-mxc/include/mach/mxc.h
> @@ -127,7 +127,7 @@ extern unsigned int __mxc_cpu_type;
> # define cpu_is_mx35() (0)
> #endif
>
> -#ifdef CONFIG_ARCH_MX50
> +#ifdef CONFIG_SOC_IMX50
> # ifdef mxc_cpu_type
> # undef mxc_cpu_type
> # define mxc_cpu_type __mxc_cpu_type
> @@ -139,7 +139,7 @@ extern unsigned int __mxc_cpu_type;
> # define cpu_is_mx50() (0)
> #endif
>
> -#ifdef CONFIG_ARCH_MX51
> +#ifdef CONFIG_SOC_IMX51
> # ifdef mxc_cpu_type
> # undef mxc_cpu_type
> # define mxc_cpu_type __mxc_cpu_type
> @@ -151,7 +151,7 @@ extern unsigned int __mxc_cpu_type;
> # define cpu_is_mx51() (0)
> #endif
>
> -#ifdef CONFIG_ARCH_MX53
> +#ifdef CONFIG_SOC_IMX53
> # ifdef mxc_cpu_type
> # undef mxc_cpu_type
> # define mxc_cpu_type __mxc_cpu_type
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index c895922..450afc5 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -476,7 +476,7 @@ config MTD_NAND_MPC5121_NFC
>
> config MTD_NAND_MXC
> tristate "MXC NAND support"
> - depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || ARCH_MX51
> + depends on IMX_HAVE_PLATFORM_MXC_NAND
> help
> This enables the driver for the NAND flash controller on the
> MXC processors.
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index bb233a9..9f9d3f7 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -164,10 +164,10 @@ config SPI_IMX_VER_0_4
> def_bool y if ARCH_MX31
>
> config SPI_IMX_VER_0_7
> - def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
> + def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
>
> config SPI_IMX_VER_2_3
> - def_bool y if ARCH_MX51 || ARCH_MX53
> + def_bool y if SOC_IMX51 || SOC_IMX53
>
> config SPI_IMX
> tristate "Freescale i.MX SPI controllers"
> --
> 1.7.1
>
>
>
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Add ARMLEX4210 Board support file
From: Kyungmin Park @ 2011-03-03 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10012655.143611299137229715.JavaMail.weblogic@epml15>
On Thu, Mar 3, 2011 at 4:27 PM, ALIM AKHTAR <alim.akhtar@samsung.com> wrote:
> This patch is based on 'for-next' ?branch of kgene tree.
>
> This patch adds Samsung ARMLEX4210 ?board support file
> which is based on Exynos4210.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> ---
> ?arch/arm/mach-exynos4/Kconfig ? ? ? ? ? | ? 13 ++
> ?arch/arm/mach-exynos4/Makefile ? ? ? ? ?| ? ?1 +
> ?arch/arm/mach-exynos4/mach-armlex4210.c | ?213 +++++++++++++++++++++++++++++++
> ?3 files changed, 227 insertions(+), 0 deletions(-)
> ?create mode 100644 arch/arm/mach-exynos4/mach-armlex4210.c
>
> diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
> index ad03840..a12bddf 100644
> --- a/arch/arm/mach-exynos4/Kconfig
> +++ b/arch/arm/mach-exynos4/Kconfig
> @@ -109,6 +109,19 @@ config MACH_SMDKV310
> ? ? ? ?help
> ? ? ? ? ?Machine support for Samsung SMDKV310
>
> +config MACH_ARMLEX4210
> + ? ? ? bool "ARMLEX4210"
> + ? ? ? select CPU_EXYNOS4210
> + ? ? ? select S3C_DEV_RTC
> + ? ? ? select S3C_DEV_WDT
> + ? ? ? select S3C_DEV_HSMMC
> + ? ? ? select S3C_DEV_HSMMC2
> + ? ? ? select S3C_DEV_HSMMC3
> + ? ? ? select EXYNOS4_DEV_SYSMMU
> + ? ? ? select EXYNOS4_SETUP_SDHCI
> + ? ? ? help
> + ? ? ? ? Machine support for Samsung ARMLEX4210 based on EXYNOS4210
> +
> ?config MACH_UNIVERSAL_C210
> ? ? ? ?bool "Mobile UNIVERSAL_C210 Board"
> ? ? ? ?select CPU_EXYNOS4210
> diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
> index 0558235..2860af8 100644
> --- a/arch/arm/mach-exynos4/Makefile
> +++ b/arch/arm/mach-exynos4/Makefile
> @@ -24,6 +24,7 @@ obj-$(CONFIG_HOTPLUG_CPU) ? ? += hotplug.o
>
> ?obj-$(CONFIG_MACH_SMDKC210) ? ? ? ? ? ?+= mach-smdkc210.o
> ?obj-$(CONFIG_MACH_SMDKV310) ? ? ? ? ? ?+= mach-smdkv310.o
> +obj-$(CONFIG_MACH_ARMLEX4210) ? ? ? ? ?+= mach-armlex4210.o
> ?obj-$(CONFIG_MACH_UNIVERSAL_C210) ? ? ?+= mach-universal_c210.o
>
> ?# device support
> diff --git a/arch/arm/mach-exynos4/mach-armlex4210.c b/arch/arm/mach-exynos4/mach-armlex4210.c
> new file mode 100644
> index 0000000..856ab6e
> --- /dev/null
> +++ b/arch/arm/mach-exynos4/mach-armlex4210.c
> @@ -0,0 +1,213 @@
> +/* linux/arch/arm/mach-exynos4/mach-armlex4210.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * ? ? ? ? ? ? http://www.samsung.com
> + *
> + * 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.
> +*/
> +
> +#include <linux/gpio.h>
> +#include <linux/io.h>
> +#include <linux/mmc/host.h>
> +#include <linux/platform_device.h>
> +#include <linux/serial_core.h>
> +#include <linux/smsc911x.h>
> +
> +#include <asm/mach/arch.h>
> +#include <asm/mach-types.h>
> +
> +#include <plat/cpu.h>
> +#include <plat/devs.h>
> +#include <plat/exynos4.h>
> +#include <plat/gpio-cfg.h>
> +#include <plat/regs-serial.h>
> +#include <plat/regs-srom.h>
> +#include <plat/sdhci.h>
> +
> +#include <mach/map.h>
> +
> +/* Following are default values for UCON, ULCON and UFCON UART registers */
> +#define ARMLEX4210_UCON_DEFAULT ? ? ? ?(S3C2410_UCON_TXILEVEL | ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?S3C2410_UCON_RXILEVEL | ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?S3C2410_UCON_TXIRQMODE | ? ? ? \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?S3C2410_UCON_RXIRQMODE | ? ? ? \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?S3C2410_UCON_RXFIFO_TOI | ? ? ?\
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?S3C2443_UCON_RXERR_IRQEN)
> +
> +#define ARMLEX4210_ULCON_DEFAULT ? ? ? S3C2410_LCON_CS8
> +
> +#define ARMLEX4210_UFCON_DEFAULT ? ? ? (S3C2410_UFCON_FIFOMODE | ? ? ? \
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?S5PV210_UFCON_TXTRIG4 | ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?S5PV210_UFCON_RXTRIG4)
> +
> +static struct s3c2410_uartcfg armlex4210_uartcfgs[] __initdata = {
> + ? ? ? [0] = {
> + ? ? ? ? ? ? ? .hwport ? ? ? ? = 0,
> + ? ? ? ? ? ? ? .flags ? ? ? ? ?= 0,
> + ? ? ? ? ? ? ? .ucon ? ? ? ? ? = ARMLEX4210_UCON_DEFAULT,
> + ? ? ? ? ? ? ? .ulcon ? ? ? ? ?= ARMLEX4210_ULCON_DEFAULT,
> + ? ? ? ? ? ? ? .ufcon ? ? ? ? ?= ARMLEX4210_UFCON_DEFAULT,
> + ? ? ? },
> + ? ? ? [1] = {
> + ? ? ? ? ? ? ? .hwport ? ? ? ? = 1,
> + ? ? ? ? ? ? ? .flags ? ? ? ? ?= 0,
> + ? ? ? ? ? ? ? .ucon ? ? ? ? ? = ARMLEX4210_UCON_DEFAULT,
> + ? ? ? ? ? ? ? .ulcon ? ? ? ? ?= ARMLEX4210_ULCON_DEFAULT,
> + ? ? ? ? ? ? ? .ufcon ? ? ? ? ?= ARMLEX4210_UFCON_DEFAULT,
> + ? ? ? },
> + ? ? ? [2] = {
> + ? ? ? ? ? ? ? .hwport ? ? ? ? = 2,
> + ? ? ? ? ? ? ? .flags ? ? ? ? ?= 0,
> + ? ? ? ? ? ? ? .ucon ? ? ? ? ? = ARMLEX4210_UCON_DEFAULT,
> + ? ? ? ? ? ? ? .ulcon ? ? ? ? ?= ARMLEX4210_ULCON_DEFAULT,
> + ? ? ? ? ? ? ? .ufcon ? ? ? ? ?= ARMLEX4210_UFCON_DEFAULT,
> + ? ? ? },
> + ? ? ? [3] = {
> + ? ? ? ? ? ? ? .hwport ? ? ? ? = 3,
> + ? ? ? ? ? ? ? .flags ? ? ? ? ?= 0,
> + ? ? ? ? ? ? ? .ucon ? ? ? ? ? = ARMLEX4210_UCON_DEFAULT,
> + ? ? ? ? ? ? ? .ulcon ? ? ? ? ?= ARMLEX4210_ULCON_DEFAULT,
> + ? ? ? ? ? ? ? .ufcon ? ? ? ? ?= ARMLEX4210_UFCON_DEFAULT,
> + ? ? ? },
> +};
> +
> +static struct s3c_sdhci_platdata armlex4210_hsmmc0_pdata __initdata = {
> + ? ? ? .cd_type ? ? ? ? ? ? ? ?= S3C_SDHCI_CD_PERMANENT,
> + ? ? ? .clk_type ? ? ? ? ? ? ? = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
> + ? ? ? .max_width ? ? ? ? ? ? ?= 8,
> + ? ? ? .host_caps ? ? ? ? ? ? ?= MMC_CAP_8_BIT_DATA,
> +#endif
> +};
> +
> +static struct s3c_sdhci_platdata armlex4210_hsmmc2_pdata __initdata = {
> + ? ? ? .cd_type ? ? ? ? ? ? ? ?= S3C_SDHCI_CD_GPIO,
> + ? ? ? .ext_cd_gpio ? ? ? ? ? ?= EXYNOS4_GPX2(5),
> + ? ? ? .ext_cd_gpio_invert ? ? = 1,
> + ? ? ? .clk_type ? ? ? ? ? ? ? = S3C_SDHCI_CLK_DIV_EXTERNAL,
> + ? ? ? .max_width ? ? ? ? ? ? ?= 4,
> +};
> +
> +static struct s3c_sdhci_platdata armlex4210_hsmmc3_pdata __initdata = {
> + ? ? ? .cd_type ? ? ? ? ? ? ? ?= S3C_SDHCI_CD_PERMANENT,
> + ? ? ? .max_width ? ? ? ? ? ? ?= 4,
maybe you missed the clk_type. It's required for exynos4 series.
clk_type ? ? ? ? ? ? ? = S3C_SDHCI_CLK_DIV_EXTERNAL,
> +};
> +
> +static void __init armlex4210_sdhci_init(void)
> +{
> + ? ? ? s3c_sdhci0_set_platdata(&armlex4210_hsmmc0_pdata);
> + ? ? ? s3c_sdhci2_set_platdata(&armlex4210_hsmmc2_pdata);
> + ? ? ? s3c_sdhci3_set_platdata(&armlex4210_hsmmc3_pdata);
> +}
> +
> +static void __init armlex4210_wlan_init(void)
> +{
> + ? ? ? /* enable */
> + ? ? ? s3c_gpio_cfgpin(EXYNOS4_GPX2(0), S3C_GPIO_SFN(0xf));
> + ? ? ? s3c_gpio_setpull(EXYNOS4_GPX2(0), S3C_GPIO_PULL_UP);
> +
> + ? ? ? /* reset */
> + ? ? ? s3c_gpio_cfgpin(EXYNOS4_GPX1(6), S3C_GPIO_SFN(0xf));
> + ? ? ? s3c_gpio_setpull(EXYNOS4_GPX1(6), S3C_GPIO_PULL_UP);
> +
> + ? ? ? /* wakeup */
> + ? ? ? s3c_gpio_cfgpin(EXYNOS4_GPX1(5), S3C_GPIO_SFN(0xf));
> + ? ? ? s3c_gpio_setpull(EXYNOS4_GPX1(5), S3C_GPIO_PULL_UP);
> +}
> +
> +static struct resource armlex4210_smsc911x_resources[] = {
> + ? ? ? [0] = {
> + ? ? ? ? ? ? ? .start ?= EXYNOS4_PA_SROM_BANK(3),
> + ? ? ? ? ? ? ? .end ? ?= EXYNOS4_PA_SROM_BANK(3) + SZ_64K - 1,
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_MEM,
> + ? ? ? },
> + ? ? ? [1] = {
> + ? ? ? ? ? ? ? .start ?= IRQ_EINT(27),
> + ? ? ? ? ? ? ? .end ? ?= IRQ_EINT(27),
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_IRQ | IRQF_TRIGGER_HIGH,
> + ? ? ? },
> +};
> +
> +static struct smsc911x_platform_config smsc9215_config = {
> + ? ? ? .irq_polarity ? = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH,
> + ? ? ? .irq_type ? ? ? = SMSC911X_IRQ_TYPE_PUSH_PULL,
> + ? ? ? .flags ? ? ? ? ?= SMSC911X_USE_16BIT | SMSC911X_FORCE_INTERNAL_PHY,
> + ? ? ? .phy_interface ?= PHY_INTERFACE_MODE_MII,
> + ? ? ? .mac ? ? ? ? ? ?= {0x00, 0x80, 0x00, 0x23, 0x45, 0x67},
> +};
> +
> +static struct platform_device armlex4210_smsc911x = {
> + ? ? ? .name ? ? ? ? ? = "smsc911x",
> + ? ? ? .id ? ? ? ? ? ? = -1,
> + ? ? ? .num_resources ?= ARRAY_SIZE(armlex4210_smsc911x_resources),
> + ? ? ? .resource ? ? ? = armlex4210_smsc911x_resources,
> + ? ? ? .dev ? ? ? ? ? ?= {
> + ? ? ? ? ? ? ? .platform_data ?= &smsc9215_config,
> + ? ? ? },
> +};
> +
> +static struct platform_device *armlex4210_devices[] __initdata = {
> + ? ? ? &s3c_device_hsmmc0,
> + ? ? ? &s3c_device_hsmmc2,
> + ? ? ? &s3c_device_hsmmc3,
> + ? ? ? &s3c_device_rtc,
> + ? ? ? &s3c_device_wdt,
> + ? ? ? &exynos4_device_sysmmu,
> + ? ? ? &samsung_asoc_dma,
> + ? ? ? &armlex4210_smsc911x,
> +};
> +
> +static void __init armlex4210_smsc911x_init(void)
> +{
> + ? ? ? u32 cs1;
> +
> + ? ? ? /* configure nCS1 width to 16 bits */
> + ? ? ? cs1 = __raw_readl(S5P_SROM_BW) &
> + ? ? ? ? ? ? ? ~(S5P_SROM_BW__CS_MASK << S5P_SROM_BW__NCS1__SHIFT);
> + ? ? ? cs1 |= ((1 << S5P_SROM_BW__DATAWIDTH__SHIFT) |
> + ? ? ? ? ? ? ? (0 << S5P_SROM_BW__WAITENABLE__SHIFT) |
> + ? ? ? ? ? ? ? (1 << S5P_SROM_BW__ADDRMODE__SHIFT) |
> + ? ? ? ? ? ? ? (1 << S5P_SROM_BW__BYTEENABLE__SHIFT)) <<
> + ? ? ? ? ? ? ? S5P_SROM_BW__NCS1__SHIFT;
> + ? ? ? __raw_writel(cs1, S5P_SROM_BW);
> +
> + ? ? ? /* set timing for nCS1 suitable for ethernet chip */
> + ? ? ? __raw_writel((0x1 << S5P_SROM_BCX__PMC__SHIFT) |
> + ? ? ? ? ? ? ? ? ? ?(0x9 << S5P_SROM_BCX__TACP__SHIFT) |
> + ? ? ? ? ? ? ? ? ? ?(0xc << S5P_SROM_BCX__TCAH__SHIFT) |
> + ? ? ? ? ? ? ? ? ? ?(0x1 << S5P_SROM_BCX__TCOH__SHIFT) |
> + ? ? ? ? ? ? ? ? ? ?(0x6 << S5P_SROM_BCX__TACC__SHIFT) |
> + ? ? ? ? ? ? ? ? ? ?(0x1 << S5P_SROM_BCX__TCOS__SHIFT) |
> + ? ? ? ? ? ? ? ? ? ?(0x1 << S5P_SROM_BCX__TACS__SHIFT), S5P_SROM_BC1);
> +}
> +
> +static void __init armlex4210_map_io(void)
> +{
> + ? ? ? s5p_init_io(NULL, 0, S5P_VA_CHIPID);
> + ? ? ? s3c24xx_init_clocks(24000000);
> + ? ? ? s3c24xx_init_uarts(armlex4210_uartcfgs,
> + ? ? ? ? ? ? ? ? ? ? ? ? ?ARRAY_SIZE(armlex4210_uartcfgs));
> +}
> +
> +static void __init armlex4210_machine_init(void)
> +{
> + ? ? ? armlex4210_smsc911x_init();
> +
> + ? ? ? armlex4210_sdhci_init();
> +
> + ? ? ? armlex4210_wlan_init();
> +
> + ? ? ? platform_add_devices(armlex4210_devices,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?ARRAY_SIZE(armlex4210_devices));
> +}
> +
> +MACHINE_START(ARMLEX4210, "ARMLEX4210")
> + ? ? ? /* Maintainer: Alim Akhtar <alim.akhtar@samsung.com> */
> + ? ? ? .boot_params ? ?= S5P_PA_SDRAM + 0x100,
> + ? ? ? .init_irq ? ? ? = exynos4_init_irq,
> + ? ? ? .map_io ? ? ? ? = armlex4210_map_io,
> + ? ? ? .init_machine ? = armlex4210_machine_init,
> + ? ? ? .timer ? ? ? ? ?= &exynos4_timer,
> +MACHINE_END
> --
> 1.7.0.4
>
^ permalink raw reply
* [PATCH 1/2] ARM: imx5x: clean up ARCH_MX5X
From: Richard Zhao @ 2011-03-03 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110303085033.GN22310@pengutronix.de>
Hi Uwe,
On Thu, Mar 03, 2011 at 09:50:33AM +0100, Uwe Kleine-K?nig wrote:
> On Thu, Mar 03, 2011 at 04:40:02PM +0800, Richard Zhao wrote:
> > Move to SOC_SOC_IMX5X. Leave only places which prevent multi-soc
> > using ARCH_MX5X.
> >
> > Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> Looks OK, probably you need to split off the changes that touch files in
> drivers/ though.
Yes. Will Sashca merge drivers part too, or someone else?
>
> (Hmm, no diffstat?)
ah, removing "-p".
Thanks
Richard
>
> Best regards
> Uwe
>
> > diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> > index 03ec6e9..83ee088 100644
> > --- a/arch/arm/mach-mx5/Kconfig
> > +++ b/arch/arm/mach-mx5/Kconfig
> > @@ -1,5 +1,6 @@
> > if ARCH_MX5
> > -# ARCH_MX51 and ARCH_MX50 are left for compatibility
> > +# ARCH_MX50/51/53 are left to mark places where prevent multi-soc in single
> > +# image. So for most time, SOC_IMX50/51/53 should be used.
> >
> > config ARCH_MX50
> > bool
> > diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> > index 33530d2..be7df13 100644
> > --- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
> > +++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> > @@ -194,7 +194,7 @@ static int __init imxXX_add_imx_dma(void)
> > } else
> > #endif
> >
> > -#if defined(CONFIG_ARCH_MX51)
> > +#if defined(CONFIG_SOC_IMX51)
> > if (cpu_is_mx51()) {
> > imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51_to1;
> > ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
> > diff --git a/arch/arm/plat-mxc/include/mach/irqs.h b/arch/arm/plat-mxc/include/mach/irqs.h
> > index ba65c92..a3d930d 100644
> > --- a/arch/arm/plat-mxc/include/mach/irqs.h
> > +++ b/arch/arm/plat-mxc/include/mach/irqs.h
> > @@ -23,17 +23,17 @@
> > #define MXC_GPIO_IRQ_START MXC_INTERNAL_IRQS
> >
> > /* these are ordered by size to support multi-SoC kernels */
> > -#if defined CONFIG_ARCH_MX53
> > +#if defined CONFIG_SOC_IMX53
> > #define MXC_GPIO_IRQS (32 * 7)
> > #elif defined CONFIG_ARCH_MX2
> > #define MXC_GPIO_IRQS (32 * 6)
> > -#elif defined CONFIG_ARCH_MX50
> > +#elif defined CONFIG_SOC_IMX50
> > #define MXC_GPIO_IRQS (32 * 6)
> > #elif defined CONFIG_ARCH_MX1
> > #define MXC_GPIO_IRQS (32 * 4)
> > #elif defined CONFIG_ARCH_MX25
> > #define MXC_GPIO_IRQS (32 * 4)
> > -#elif defined CONFIG_ARCH_MX51
> > +#elif defined CONFIG_SOC_IMX51
> > #define MXC_GPIO_IRQS (32 * 4)
> > #elif defined CONFIG_ARCH_MXC91231
> > #define MXC_GPIO_IRQS (32 * 4)
> > diff --git a/arch/arm/plat-mxc/include/mach/mxc.h b/arch/arm/plat-mxc/include/mach/mxc.h
> > index 04c7a26..3781f2f 100644
> > --- a/arch/arm/plat-mxc/include/mach/mxc.h
> > +++ b/arch/arm/plat-mxc/include/mach/mxc.h
> > @@ -127,7 +127,7 @@ extern unsigned int __mxc_cpu_type;
> > # define cpu_is_mx35() (0)
> > #endif
> >
> > -#ifdef CONFIG_ARCH_MX50
> > +#ifdef CONFIG_SOC_IMX50
> > # ifdef mxc_cpu_type
> > # undef mxc_cpu_type
> > # define mxc_cpu_type __mxc_cpu_type
> > @@ -139,7 +139,7 @@ extern unsigned int __mxc_cpu_type;
> > # define cpu_is_mx50() (0)
> > #endif
> >
> > -#ifdef CONFIG_ARCH_MX51
> > +#ifdef CONFIG_SOC_IMX51
> > # ifdef mxc_cpu_type
> > # undef mxc_cpu_type
> > # define mxc_cpu_type __mxc_cpu_type
> > @@ -151,7 +151,7 @@ extern unsigned int __mxc_cpu_type;
> > # define cpu_is_mx51() (0)
> > #endif
> >
> > -#ifdef CONFIG_ARCH_MX53
> > +#ifdef CONFIG_SOC_IMX53
> > # ifdef mxc_cpu_type
> > # undef mxc_cpu_type
> > # define mxc_cpu_type __mxc_cpu_type
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index c895922..450afc5 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -476,7 +476,7 @@ config MTD_NAND_MPC5121_NFC
> >
> > config MTD_NAND_MXC
> > tristate "MXC NAND support"
> > - depends on ARCH_MX2 || ARCH_MX25 || ARCH_MX3 || ARCH_MX51
> > + depends on IMX_HAVE_PLATFORM_MXC_NAND
> > help
> > This enables the driver for the NAND flash controller on the
> > MXC processors.
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > index bb233a9..9f9d3f7 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -164,10 +164,10 @@ config SPI_IMX_VER_0_4
> > def_bool y if ARCH_MX31
> >
> > config SPI_IMX_VER_0_7
> > - def_bool y if ARCH_MX25 || ARCH_MX35 || ARCH_MX51 || ARCH_MX53
> > + def_bool y if ARCH_MX25 || ARCH_MX35 || SOC_IMX51 || SOC_IMX53
> >
> > config SPI_IMX_VER_2_3
> > - def_bool y if ARCH_MX51 || ARCH_MX53
> > + def_bool y if SOC_IMX51 || SOC_IMX53
> >
> > config SPI_IMX
> > tristate "Freescale i.MX SPI controllers"
> > --
> > 1.7.1
> >
> >
> >
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* [RFC PATCH 13/20] ARM: msm: dynamically register local timer setup function
From: Marc Zyngier @ 2011-03-03 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ya39n5ntzt.fsf@huya.qualcomm.com>
On Wed, 2011-03-02 at 12:32 -0800, David Brown wrote:
David,
> On Wed, Mar 02 2011, Marc Zyngier wrote:
>
> > ---
> > arch/arm/mach-msm/timer.c | 22 +++++++++++++++++++---
> > 1 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
> > index 56f920c..e029363 100644
> > --- a/arch/arm/mach-msm/timer.c
> > +++ b/arch/arm/mach-msm/timer.c
> > @@ -228,6 +243,8 @@ static void __init msm_timer_init(void)
> > writel(DGT_CLK_CTL_DIV_4, MSM_TMR_BASE + DGT_CLK_CTL);
> > #endif
> >
> > + percpu_timer_register(msm_timer_ops_ptr);
> > +
> > for (i = 0; i < ARRAY_SIZE(msm_clocks); i++) {
> > struct msm_clock *clock = &msm_clocks[i];
> > struct clock_event_device *ce = &clock->clockevent;
>
> I'm having difficulty figuring out what tree/branch these patches are
> based off of, so I haven't been able to test this, yet. But, so far,
> the MSM changes look coherent.
>
> If you can give me a ref for your source tree, I can try to do some
> testing of these changes to make sure nothing is broken by it.
The whole serie is against -next as of yesterday, plus Will's multi-tile
support for Versatile Express, available from Russell's patch system:
http://www.arm.linux.org.uk/developer/patches/download.php?id=6771/1
It would be very helpful if you could give it a go on MSM.
Thanks,
M.
--
Reality is an implementation detail.
^ permalink raw reply
* [PATCH v8 1/1] PRUSS UIO driver support
From: TK, Pratheesh Gangadhar @ 2011-03-03 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201103021422.27094.arnd@arndb.de>
Hi,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Wednesday, March 02, 2011 6:52 PM
> On Wednesday 02 March 2011, Pratheesh Gangadhar wrote:
> > +
> > +static struct clk *pruss_clk;
> > +static struct uio_info *info;
> > +static dma_addr_t sram_paddr, ddr_paddr;
> > +static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
> > +
>
> To my initial comment about these being single-instance
> variables, you said you'd change that, which has not happened
> yet.
>
I will do this in next version. Also realized that in next SoC,
PRU INTC base offset is different, so plan to add a platform_data
variable to make this portable.
+#define PINTC_HIDISR 0x4038
+#define PINTC_HIPIR 0x4900
+#define PINTC_HIER 0x5500
These hard coding also need to go to make it fully portable.
+int intr_bit = (irq - IRQ_DA8XX_EVTOUT0 + 2);
+p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
> Also, I now noticed that the types are wrong, you are
> missing __iomem annotations for MMIO ranges. Please make
> sure that the code builds fine with sparse and "make C=1",
> which will tell you about these problems.
>
Thanks, this also helped to identify 2 unused lines in the code.
+ p->mem[1].internal_addr = sram_vaddr;
+ p->mem[2].internal_addr = ddr_vaddr;
Pratheesh
^ permalink raw reply
* [PATCH v8 1/1] PRUSS UIO driver support
From: TK, Pratheesh Gangadhar @ 2011-03-03 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103022155030.2701@localhost6.localdomain6>
Hi,
> -----Original Message-----
> From: Thomas Gleixner [mailto:tglx at linutronix.de]
> Sent: Thursday, March 03, 2011 2:27 AM
> On Wed, 2 Mar 2011, Arnd Bergmann wrote:
>
> > On Wednesday 02 March 2011 21:09:56 Hans J. Koch wrote:
> > > > +static struct uio_info *info;
> > > > +static dma_addr_t sram_paddr, ddr_paddr;
> > > > +static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
> > >
> > > So the correct thing would be
> > >
> > > static void __iomem *prussio_vaddr;
> > > static void *sram_vaddr, *ddr_vaddr;
> >
> > I also commented that it should not be a global variable at
> > all, but a dynamic data structure referenced from the device.
> >
> > Not important, but Pratheesh said he'd change it. If it stays
> > a global variable, I'd at least expect an explanation why
> > the static variable is considered better in this case.
>
> I did not pick at that, because there is no indicator that we'll see
> more than one PRUSS unit per SoC in the forseeable future.
>
It's a possibility - May be in 2-3 years time.
Thanks,
Pratheesh
^ permalink raw reply
* [PATCH] OMAP2+: PM: Warn users of sleep_while_idle if !CONFIG_CPU_IDLE
From: Rajendra Nayak @ 2011-03-03 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sjv6h5h2.fsf@ti.com>
On Wednesday 02 March 2011 03:24 AM, Kevin Hilman wrote:
> Rajendra Nayak<rnayak@ti.com> writes:
>
>> This should help users who do a
>> 'echo 1> /debug/pm_debug/sleep_while_idle' with a
>> config which has !CONFIG_CPU_IDLE and wonder
>> why OMAP is'nt sleeping in idle.
>
> This isn't quite right, as 'sleep_while_idle' is actually a flag for
> whether or not to call omap_sram_idle() at all.
Hi Kevin,
I know this is used in 'omap3_pm_idle' as well
to decide whether or not to call omap_sram_idle() but
I was'nt quite sure what omap3_pm_idle is expected to do
in the first place.
We end up calling omap_sram_idle here without really
programming any target state. Do we really need this to
happen, instead can't we just rely on ARM generic code
to do a WFI in case we don't have cpuidle support enabled?
regards,
Rajendra
>
> Even without CPUidle, WFI will still be attempted.
>
> Kevin
>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> ---
>> arch/arm/mach-omap2/pm-debug.c | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
>> index 125f565..1e722a0 100644
>> --- a/arch/arm/mach-omap2/pm-debug.c
>> +++ b/arch/arm/mach-omap2/pm-debug.c
>> @@ -569,6 +569,10 @@ static int option_get(void *data, u64 *val)
>>
>> *val = *option;
>>
>> +#ifndef CONFIG_CPU_IDLE
>> + if (option ==&sleep_while_idle)
>> + pr_warn("CONFIG_CPU_IDLE is not enabled\n");
>> +#endif
>> return 0;
>> }
>>
>> @@ -581,6 +585,11 @@ static int option_set(void *data, u64 val)
>>
>> *option = val;
>>
>> +#ifndef CONFIG_CPU_IDLE
>> + if (option ==&sleep_while_idle)
>> + pr_warn("CONFIG_CPU_IDLE is not enabled\n");
>> +#endif
>> +
>> if (option ==&enable_off_mode) {
>> if (val)
>> omap_pm_enable_off_mode();
^ permalink raw reply
* [PATCH 1/3] ARM: S5P: Rename MIPI-CSIS header and update Copyright
From: Sylwester Nawrocki @ 2011-03-03 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01a501cbd95c$37069cf0$a513d6d0$%kim@samsung.com>
On 03/03/2011 05:33 AM, Kukjin Kim wrote:
> Sylwester Nawrocki wrote:
>>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>> arch/arm/plat-s5p/dev-csis0.c | 2 +-
>> arch/arm/plat-s5p/dev-csis1.c | 2 +-
>> arch/arm/plat-s5p/include/plat/csis.h | 28
> --------------------------
>> --
>> arch/arm/plat-s5p/include/plat/mipi_csis.h | 28
>> ++++++++++++++++++++++++++++
>> 4 files changed, 30 insertions(+), 30 deletions(-)
>> delete mode 100644 arch/arm/plat-s5p/include/plat/csis.h
>> create mode 100644 arch/arm/plat-s5p/include/plat/mipi_csis.h
>>
> Oops, why didn't use '-M'?
> It can show me this like following.
>
Yes, I could do better. Sorry, I had two version of the patch
and somehow ended up with te wrong one being send.
> .../plat-s5p/include/plat/{csis.h => mipi_csis.h} | 10 +++++-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
> rename arch/arm/plat-s5p/include/plat/{csis.h => mipi_csis.h} (68%)
>
> Secondly, I remember this...
> Following is your response at that time.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/038037.ht
> ml
>
Yes, but afterwards I realized there will be issues when one is trying
to build common kernel binary for multiple SoCs.
Nevertheless I will prepare common code for S5P and a callback into platform
code, so at least we can move on with the v4l driver.
Thanks,
--
Sylwester Nawrocki
Samsung Poland R&D Center
^ permalink raw reply
* [PATCHv1] ARM: imx: Add support for low power suspend on MX51.
From: Uwe Kleine-König @ 2011-03-03 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103022343410.2701@localhost6.localdomain6>
Guten Morgen Thomas,
On Thu, Mar 03, 2011 at 12:51:32AM +0100, Thomas Gleixner wrote:
> Uwe,
>
> On Wed, 2 Mar 2011, Uwe Kleine-K?nig wrote:
> > On Wed, Mar 02, 2011 at 11:17:58AM -0600, Dinh.Nguyen at freescale.com wrote:
> > > From: Dinh Nguyen <Dinh.Nguyen@freescale.com>
>
> > > --- /dev/null
> > > +++ b/arch/arm/mach-mx5/pm.c
> > I'd like to have that called pm-imx51.c
>
> And I'd like to have a pony.
http://www.carl-russ-schule.de/files/Pony.jpg
>
> > > + ccm_clpcr |= (0x3 << MXC_CCM_CLPCR_STBY_COUNT_OFFSET);
> > the parentheses aren't needed here
>
> Could you finally provide a patch to checkpatch.pl or git commit which
> resolves that issue once and forever ?
>
> Not to mention the fact, that those parentheses are not disturbing the
> readability of that code at all.
So it seems we're different.
>
> > > + ccm_clpcr |= (0x1 << MXC_CCM_CLPCR_LPM_OFFSET);
> > ditto
>
> Ditto.
>
> > > +static int __init mx5_pm_init(void)
> > I'd prefer to have that called by imx51_init_early.
>
> And the reason is?
>
> 1) your personal preference
> 2) there is some useful technical reason
>
> If #1, then this comment was just waste of electrons
> If #2, you failed to provide some reasonable explanation
Actually it's #2, and to quote a different review[1]:
Reviewers hint to a correct solution and you are supposed to
lookup what that solution means and act accordingly. If you do
not understand the hint or its implications please ask [...]
> Again, I'd like to have a pony.
http://h-6.abload.de/img/pony01_pixelquelle_dal8701.jpg
> Seriously, while all of us admire your invaluable skills of running
> scripts over patches and kernel code, that kind of review you are
> trying to provide is utterly useless.
actually it's not a script, but I guess that doesn't matter much.
> 1) The patch itself has been questioned about its correctness hours
> before you added the output of your secret script. It was already
> reported to be non functional. So what's the value of adding
> scriptable review to it?
It might save the patch sender from a third iteration.
> 2) As long as you do not see the most obvious functional problems with
> a patch please spare your script computing power and the bandwidth
> you are consuming by your futile attempts to gain a profile as a
> patch reviewer.
The functionallity of the patch has been questioned before so I didn't
see a value in repeating that :-) To be honest, I didn't check for
functional problems, but IMHO it's OK to provide feedback about a part
of the problems if you don't see all of them.
Best regards
Uwe
[1] http://article.gmane.org/gmane.linux.kernel/1107265
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: imx: move selection between i.MX21 and i.MX27 to CPU family choice
From: Uwe Kleine-König @ 2011-03-03 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110303052653.GA19961@b20223-02.ap.freescale.net>
Hi Richard,
On Thu, Mar 03, 2011 at 01:26:54PM +0800, Richard Zhao wrote:
> On Wed, Mar 02, 2011 at 06:23:05PM +0100, Uwe Kleine-K?nig wrote:
> > The only use of selecting MX2-based before was to get the choice to select
> > between i.MX21 and i.MX27. So better provide this choice directly.
> >
> > Note that this has an influence on reduced i.MX21 configs because the
> > former default "MACH_MX21" for the "CPUs" choice makes MACH_MX21 not
> > appear in the reduced config and so the default for "Freescale CPU family:"
> > (i.e. ARCH_MX3) is used now. mx21_defconfig is adapted not to be affected
> > by this problem.
> >
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > -config ARCH_MX2
> > - bool "MX2-based"
> > +config MACH_MX21
> > + bool "MX21-based"
> > + select ARCH_MX2
> > help
> > - This enables support for systems based on the Freescale i.MX2 family
> > + This enables support for systems based on the Freescale i.MX21 family
> Is it ToDo marker like ARCH_51? Why is it MACH_xx while others are ARCH_XX?
this is done to keep existing code working. MACH_MX21 and MACH_MX27 are
used in drivers/.
> It might be little strange that mx2x is a excetion while others are grouped.
This is good, it might make people aware that there is still work to do.
:-) After the first steps for a multi-SoC-kernel are done, the grouping
has to change anyhow and doesn't match cpu families anymore. Moreover
MX2 is (IMHO) a marketing name, e.g. because i.MX25 is too different
compared to i.MX21 and i.MX27. And note that i.MX25 had a seperat entry
already before.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* CONFIG_ARM_DMA_MEM_BUFFERABLE and readl/writel weirdness
From: Catalin Marinas @ 2011-03-03 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6F481B.8000700@codeaurora.org>
On Thu, 2011-03-03 at 07:49 +0000, Saravana Kannan wrote:
> On 03/02/2011 12:39 AM, Russell King - ARM Linux wrote:
> > On Tue, Mar 01, 2011 at 05:23:15PM -0800, Saravana Kannan wrote:
> >> If I'm not missing some magic, this would mean that
> >> "CONFIG_ARM_DMA_MEM_BUFFERABLE" determines if readl(s)/writel(s) get to
> >> have a built in mb() or not.
[...]
> > I think you misunderstand what's going on. IO accesses are always ordered
> > with respect to themselves. The barriers are there to ensure ordering
> > between DMA coherent memory (normal non-cached memory) and IO accesses
> > (device).
>
> Unfortunately this is not correct. The ARM spec doesn't guarantee that
> all IO accesses should be ordered with respect to themselves. It only
> requires that the ordering should be guaranteed at least within a 1KB
> region.
That's because the CPU does not have control of the delays on various
buses. But a device connected to the same bus receives the accesses in
order.
> And the most critical point is hidden in a comment that goes:
> "The size of a memory mapped peripheral, or a block of memory, is
> IMPLEMENTATION DEFINED, but is not smaller than 1KByte."
>
> I guess most of the confusion is due to the ARM spec not being very
> obvious about the 1KB limitation.
What that means is that the hardware shouldn't have two different buses
(possibly with different delays) within a 1KB range.
Even if accesses to all peripherals are ordered, you still cannot
guarantee that a writel() would change the state of a device (and that's
specific to all architectures). Sometimes if you want to make sure the
device state changed you need a readl() back.
> So, going back to my point, I think it's wrong for
> CONFIG_ARM_DMA_MEM_BUFFERABLE to control how stuff unrelated to DMA behaves.
In an ideal world, all driver authors know what memory ordering is and
add the necessary barriers. But since that's not the case, the only way
to get ordering between Normal Non-cacheable access (DMA buffer) and
Device access (via writel) is to add the mb() in the I/O accessors.
This has been discussed at length on several occasions on linux-arch and
LKML. We don't have other solution since adding barriers to drivers
wasn't found feasible by others. Of course, if you can optimised your
driver to use the relaxed accessors and add explicit barriers.
> I have also encountered a few people who kept went "but readl/writel was
> recently changed to add mem barriers, so we can all remove the mb()s in
> our driver (unrelated to DMA) code".
But why did they have those barriers around I/O accessors in the first
place? As you say, nothing related to DMA. If you access two different
devices and want to ensure an ordering of the state changes, I doubt a
barrier would help. Most likely you need a read back from the device.
> That would have made their code incorrect for two reasons:
> 1. readl/writel doesn't always have a mem barrier because of config that
> can be turned off.
> 2. In cases where readl/writel didn't have mb(), there is not enough
> ordering guarantee without an explicit mb().
See my comment above, what do they try to achieve by using mb() around
already ordered I/O accessors?
> I think as a community, we should stop saying that readl/writel ensures
> ordering with respect to all IO accesses. It doesn't even guarantee
> ordering within the same device (when their register regions are > 1KB).
It definitely guarantees ordering to the same device. The 1KB is a
minimum limit but there is no upper bound (and it should definitely
cover a single device).
> After reading the above, please let me know if a patch to decouple the
> "readl/writel with builtin mb()" from CONFIG_ARM_DMA_MEM_BUFFERABLE
> would be accepted. If so, I can go ahead and send it out soon.
No, I don't think this would be acceptable. I can point you to past
discussion where Linus stated that Normal Non-cacheable memory and I/O
accesses should be ordered.
What you can do actually is make sure that all architectures support the
relaxed accessors and change the drivers to use these instead.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox