* [PATCH 2/9] regulator: helper routine to extract regulator_init_data
From: Mark Brown @ 2011-09-27 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E81E224.2070408@ti.com>
On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> >>+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> >>+ GFP_KERNEL);
> >>+ if (!init_data)
> >>+ return NULL; /* Out of memory? */
> >This means that the init data will be kept around for the entire
> >lifetime of the device rather than being discarded.
> Wasn't it the same while this was passed around as platform_data?
It was in the past but I remember fixing it at some point. Perhaps I'm
imagining things.
> >>+ init_data->supply_regulator = (char *)of_get_property(dev->of_node,
> >>+ "regulator-supplies", NULL);
> >I'd expect that in the device tree world the supply regulator would
> >reference the node for that regulator.
> You mean using phandles? Thats what Grant proposed too but
> I thought you instead had an inclination towards names? Or maybe
> I misunderstood.
They need both. We need to reference the device that provides the
supply and use a name to say which of the potentially multiple supplies
on the consumer device is which.
> >Hrm, I think loosing the signs here is bad karma - negative voltages do
> >exist after all.
> Oops.. they do? didn't know about that.
Yup, ground is just a reference point.
^ permalink raw reply
* [PATCH v3 4/6] arm/imx6q: add smp and cpu hotplug support
From: Shawn Guo @ 2011-09-27 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927134401.GE17997@S2100-06.ap.freescale.net>
On Tue, Sep 27, 2011 at 09:44:02PM +0800, Shawn Guo wrote:
> On Mon, Sep 26, 2011 at 01:06:34PM +0200, Sascha Hauer wrote:
> > On Mon, Sep 26, 2011 at 03:20:49PM +0800, Shawn Guo wrote:
> > > It adds smp and cpu hotplug support for imx6q.
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > ---
> > > arch/arm/mach-imx/Kconfig | 1 +
> > > arch/arm/mach-imx/Makefile | 4 ++
> > > arch/arm/mach-imx/head-v7.S | 71 ++++++++++++++++++++++++++
> > > arch/arm/mach-imx/hotplug.c | 44 ++++++++++++++++
> > > arch/arm/mach-imx/localtimer.c | 35 +++++++++++++
> > > arch/arm/mach-imx/platsmp.c | 85 +++++++++++++++++++++++++++++++
> > > arch/arm/plat-mxc/include/mach/common.h | 5 ++
> > > 7 files changed, 245 insertions(+), 0 deletions(-)
> > > create mode 100644 arch/arm/mach-imx/head-v7.S
> > > create mode 100644 arch/arm/mach-imx/hotplug.c
> > > create mode 100644 arch/arm/mach-imx/localtimer.c
> > > create mode 100644 arch/arm/mach-imx/platsmp.c
> > >
> > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > > index af73b3e..6ec758d 100644
> > > --- a/arch/arm/mach-imx/Kconfig
> > > +++ b/arch/arm/mach-imx/Kconfig
> > > @@ -623,6 +623,7 @@ config SOC_IMX6Q
> > > bool "i.MX6 Quad support"
> > > select ARM_GIC
> > > select CPU_V7
> > > + select HAVE_ARM_SCU
> > > select HAVE_IMX_GPC
> > > select HAVE_IMX_MMDC
> > > select HAVE_IMX_SRC
> > > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> > > index 8c21fda..d46b2e7 100644
> > > --- a/arch/arm/mach-imx/Makefile
> > > +++ b/arch/arm/mach-imx/Makefile
> > > @@ -66,4 +66,8 @@ obj-$(CONFIG_DEBUG_LL) += lluart.o
> > > obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
> > > obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
> > > obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> > > +obj-$(CONFIG_CPU_V7) += head-v7.o
> >
> > Can we have a
> >
> > AFLAGS_head-v7.o :=-Wa,-march=armv7-a
> >
> > here?
> >
> > Then you only have to adjust some Kconfig variables and can compile
> > i.MX3 and i.MX6 together. I just gave it a test and it works on i.MX3, I
> > don't have a i.MX6 platform to test on though.
> >
> I tested it on imx6q, and it does not work. I tracked it to the point
> at mxc_init_l2x0() which is an early_initcall. Because we do not have
> mxc_cpu_type and cpu_is_mx6q() defined, the execution goes through the
> (!cpu_is_mx31() && !cpu_is_mx35()) check and ends up with Oops on
> imx6q.
>
> I do not want to add mxc_cpu_type and cpu_is_mx6q() stuff, so I intend
> to remove early_initcall there, and let imx31/35_soc_init() explicitly
> calls mxc_init_l2x0().
>
I'm changing my mind (so quickly). It turns out we will fall into a
number of other traps if we build imx6q with imx3 without mxc_cpu_type
set up for imx6q, arch_idle(), __imx_ioremap(), etc. So for now, I
want to add mxc_cpu_type for imx6q to cooperate with all these traps.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] of: Add helpers to get one string in multiple strings property
From: Benoit Cousson @ 2011-09-27 15:45 UTC (permalink / raw)
To: linux-arm-kernel
Add of_property_read_string_index and of_property_count_strings
to retrieve one string inside a property that will contains
severals strings.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
---
drivers/of/base.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 18 +++++++++++
2 files changed, 103 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 3ff22e3..d97d53e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -662,6 +662,91 @@ int of_property_read_string(struct device_node *np, const char *propname,
EXPORT_SYMBOL_GPL(of_property_read_string);
/**
+ * of_property_read_string_index - Find and read a string from a multiple
+ * strings property.
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @index: index of the string in the list of strings
+ * @out_string: pointer to null terminated return string, modified only if
+ * return value is 0.
+ *
+ * Search for a property in a device tree node and retrieve a null
+ * terminated string value (pointer to data, not a copy) in the list of strings
+ * contained in that property.
+ * Returns 0 on
+ * success, -EINVAL if the property does not exist, -ENODATA if property
+ * does not have a value, and -EILSEQ if the string is not null-terminated
+ * within the length of the property data.
+ *
+ * The out_string pointer is modified only if a valid string can be decoded.
+ */
+int of_property_read_string_index(struct device_node *np, const char *propname,
+ int index, const char **output)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ int i = 0;
+ size_t l = 0, total = 0;
+ const char *p;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if (strnlen(prop->value, prop->length) >= prop->length)
+ return -EILSEQ;
+
+ p = prop->value;
+
+ for (i = 0; total < prop->length; total += l, p += l) {
+ l = strlen(p) + 1;
+ if ((*p != 0) && (i++ == index)) {
+ *output = p;
+ return 0;
+ }
+ }
+ return -ENODATA;
+}
+EXPORT_SYMBOL_GPL(of_property_read_string_index);
+
+
+/**
+ * of_property_count_strings - Find and return the number of strings from a
+ * multiple strings property.
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device tree node and retrieve the number of null
+ * terminated string contain in it. Returns the number of strings on
+ * success, -EINVAL if the property does not exist, -ENODATA if property
+ * does not have a value, and -EILSEQ if the string is not null-terminated
+ * within the length of the property data.
+ */
+int of_property_count_strings(struct device_node *np, const char *propname)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ int i = 0;
+ size_t l = 0, total = 0;
+ const char *p;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if (strnlen(prop->value, prop->length) >= prop->length)
+ return -EILSEQ;
+
+ p = prop->value;
+
+ for (i = 0; total < prop->length; total += l, p += l) {
+ l = strlen(p) + 1;
+ if (*p != 0)
+ i++;
+ }
+ return i;
+}
+EXPORT_SYMBOL_GPL(of_property_count_strings);
+
+/**
* of_parse_phandle - Resolve a phandle property to a device_node pointer
* @np: Pointer to device node holding phandle property
* @phandle_name: Name of property holding a phandle value
diff --git a/include/linux/of.h b/include/linux/of.h
index 9180dc5..9eadc4e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -203,6 +203,11 @@ extern int of_property_read_u32_array(const struct device_node *np,
extern int of_property_read_string(struct device_node *np,
const char *propname,
const char **out_string);
+extern int of_property_read_string_index(struct device_node *np,
+ const char *propname,
+ int index, const char **output);
+extern int of_property_count_strings(struct device_node *np,
+ const char *propname);
extern int of_device_is_compatible(const struct device_node *device,
const char *);
extern int of_device_is_available(const struct device_node *device);
@@ -256,6 +261,19 @@ static inline int of_property_read_string(struct device_node *np,
return -ENOSYS;
}
+static inline int of_property_read_string_index(struct device_node *np,
+ const char *propname, index,
+ const char **out_string)
+{
+ return -ENOSYS;
+}
+
+static inline int of_property_count_strings(struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
static inline const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp)
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
From: Cousson, Benoit @ 2011-09-27 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927014632.GB20588@ponder.secretlab.ca>
On 9/27/2011 3:46 AM, Grant Likely wrote:
> On Thu, Sep 22, 2011 at 10:52:25PM +0200, Benoit Cousson wrote:
[...]
>> +Required properties:
>> +- compatible: Every devices present in OMAP SoC should be in the
>> + form: "ti,XXX"
>> +- ti,hwmods: list of hwmods attached to a device. Must contain at least
>> + one hwmod.
>
> Nit: This should specify that ti,hwmods is a list of hwmod names
> (ascii strings), and that the hwmod names come from the OMAP
> documentation. Don't respin the patch over this though, just do a
> follow-up patch.
OK, but since you asked later to remove the DT helpers, I will have to resend it anyway:-)
[...]
>> +/*
>> + * XXX: DT helper functions that should be replaced by more generic
>> + * API introduced by Stephen Warren once they'll be in mainline.
>> + */
>> +static int _dt_count_property_string(const char *prop, int len)
>> +{
>> + int i = 0;
>> + size_t l = 0, total = 0;
>> +
>> + if (!prop || !len)
>> + return -EINVAL;
>> +
>> + for (i = 0; len>= total; total += l, prop += l) {
>> + l = strlen(prop) + 1;
>> + if (*prop != 0)
>> + i++;
>> + }
>> + return i;
>> +}
>> +
>> +static int _dt_get_property(const char *prop, int len, int index, char *output,
>> + int size)
>> +{
>> + int i = 0;
>> + size_t l = 0, total = 0;
>> +
>> + if (!prop || !len)
>> + return -EINVAL;
>> +
>> + for (i = 0; len>= total; total += l, prop += l) {
>> + l = strlcpy(output, prop, size) + 1;
>> + if (*prop != 0) {
>> + if (i++ == index)
>> + return 0;
>> + }
>> + }
>> + return -ENODEV;
>> +}
>
> Don't merge this. Kevin or I could put Stephen's patch into a separate
> branch that both Kevin and I pull. There's no need to merge temporary
> code.
>
> That said, I just looked at Stephen's iterator, and even without it
> this particular hunk shouldn't be merged here. A
> of_property_count_strings() function is useful in and of itself, and
> of_property_read_string() could be extended with an
> of_property_read_string_index() version. Both changes should be in
> the common drivers/of code, and you can easily do them.
I'm fine with that, but in that case, and in order to be consistent with the existing of_property_read_string, I should include the find_property in these functions. Whereas in my case, it was supposed to be done before.
Please find below a first version of this patch.
Regards,
Benoit
---
^ permalink raw reply
* [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config
From: Mark Brown @ 2011-09-27 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E81E25C.5080500@ti.com>
On Tue, Sep 27, 2011 at 08:19:00PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> >>+Optional properties:
> >>+- regulator-fixed-supply: Name of the regulator supply
> >This is going to be confusing with respect to the generic regulator
> >supply property.
> Yes, I guess. Any suggestions on how to make it less
> confusing? :-)
Call it display-name or something?
^ permalink raw reply
* [PATCH v7 00/26] gpio/omap: driver cleanup and fixes
From: Kevin Hilman @ 2011-09-27 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAC83ZvJ4qdyvGfJGXbhf8SsGOuvwuDzBFx-f8NZX1209KAVOYw@mail.gmail.com>
"DebBarma, Tarun Kanti" <tarun.kanti@ti.com> writes:
> On Tue, Sep 27, 2011 at 4:40 AM, Kevin Hilman <khilman@ti.com> wrote:
>> "DebBarma, Tarun Kanti" <tarun.kanti@ti.com> writes:
>>
>> [...]
>>
>>> As pointed out by Kevin, debounce clock was not getting disabled.
>>> In my testing I was somehow grepping CORE power domain instead
>>> of PER power domain and hence missed it. The fix for the debounce
>>> clock issue is at the end of the email.
>>>
>>> - Have re-based the for_3.2/gpio-cleanup branch against 3.1-rc6.
>>> - Dropped [PATCH 26/26] gpio/omap: add dbclk aliases for all gpio modules
>>> as suggested by Kevin since it's already taken care by hwmod.
>>> - Added the debounce clock fix in the end.
>>
>> That debounce fix definitely makes things look better, but it's not
>> solving the problem...
>>
>>> With above, PER is hitting low power state in Suspend and Idle path.
>>>
>>> Have pushed a branch at below URL with mentioned changes.
>>> git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
>>> for_3.2/kevin/gpio-cleanup
>>
>> I tested your branch on my 3430/n900 and PER is still not hitting
>> retention. ?Setting all debounce values in the board file to zero using
>> the patch below[1] makes PER hit retention again.
>>
>> Assuming you don't have an n900 to test with, I suggest you just copy
>> the GPIO keys init from board-rx51-peripherals.c (or some of it) into
>> the board file you are testing with.
>>
>> The problem is most likely be related to having more than one GPIO in a
>> bank with debounce enabled, or more than one bank with GPIOs enabled and
>> your current test is not be catching it.
>>
> As per commit c8c9fda506945 {OMAP: PM: disable idle on suspend for
> GPIO and UART}, the gpio code needs to be fixed once GPIO driver is
> run-time adapted.
Great, good catch.
> So I did below change as per the commit and now suspend is working
> fine even with board files change for debounce functionality. So the
> last series + below one line change is whats needed for suspend to
> work. Can you please see if this does help on your board ?
Yeah, with your patch, PER is hitting retention in suspend on my
3430/n900.
> I am not finished my idle testing yet but just reporting the suspend
> results.
For me, PER is not hitting retention on idle.
Also, your repost of v7 doesn't included any of the comments I made on
it yesterday.
Kevin
^ permalink raw reply
* [PATCH v2 0/3] Add support for tegra2 based ventana board
From: Peter De Schrijver @ 2011-09-27 17:10 UTC (permalink / raw)
To: linux-arm-kernel
This patch set adds support for the tegra2 based ventana development board.
Boot tested on ventana.
Peter De Schrijver (3):
arm/tegra: prepare Seaboard pinmux code for derived boards
arm/tegra: add support for ventana pinmuxing
arm/tegra: device tree support for ventana board
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++++++++++++
arch/arm/mach-tegra/Kconfig | 6 +++
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 5 ++-
arch/arm/mach-tegra/board-seaboard-pinmux.c | 63 ++++++++++++++++++++++++---
6 files changed, 101 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
^ permalink raw reply
* [PATCH v2 1/3] arm/tegra: prepare Seaboard pinmux code for derived boards
From: Peter De Schrijver @ 2011-09-27 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143421-27286-1-git-send-email-pdeschrijver@nvidia.com>
This patch splits out the common part of pinmux and GPIO initialization for
seaboard and derived boards. This code originates from chromeos kernel commit
772f1b56e713be7a55759c2d5eadb9eb11d078db. Author Jong Kim <jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/mach-tegra/board-seaboard-pinmux.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index 74f78b7..b31c765 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -1,5 +1,6 @@
/*
- * Copyright (C) 2010 NVIDIA Corporation
+ * Copyright (C) 2010,2011 NVIDIA Corporation
+ * Copyright (C) 2011 Google, Inc.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -160,7 +161,7 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
-static struct tegra_gpio_table gpio_table[] = {
+static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_SD2_CD, .enable = true },
{ .gpio = TEGRA_GPIO_SD2_WP, .enable = true },
{ .gpio = TEGRA_GPIO_SD2_POWER, .enable = true },
@@ -171,12 +172,17 @@ static struct tegra_gpio_table gpio_table[] = {
{ .gpio = TEGRA_GPIO_USB1, .enable = true },
};
-void __init seaboard_pinmux_init(void)
+static void __init seaboard_common_pinmux_init(void)
{
tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
tegra_drive_pinmux_config_table(seaboard_drive_pinmux,
ARRAY_SIZE(seaboard_drive_pinmux));
- tegra_gpio_config(gpio_table, ARRAY_SIZE(gpio_table));
+ tegra_gpio_config(common_gpio_table, ARRAY_SIZE(common_gpio_table));
+}
+
+void __init seaboard_pinmux_init(void)
+{
+ seaboard_common_pinmux_init();
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 2/3] arm/tegra: add support for ventana pinmuxing
From: Peter De Schrijver @ 2011-09-27 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143421-27286-1-git-send-email-pdeschrijver@nvidia.com>
Add support for ventana pinmuxing as a seaboard derivative. This is a cut down
version of chromeos kernel commit 772f1b56e713be7a55759c2d5eadb9eb11d078db
by Jong Kim <jongk@nvidia.com>.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/board-seaboard-pinmux.c | 49 +++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/Makefile b/arch/arm/mach-tegra/Makefile
index f11b910..91a07e1 100644
--- a/arch/arm/mach-tegra/Makefile
+++ b/arch/arm/mach-tegra/Makefile
@@ -31,6 +31,7 @@ obj-${CONFIG_MACH_SEABOARD} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TEGRA_DT} += board-dt.o
obj-${CONFIG_MACH_TEGRA_DT} += board-harmony-pinmux.o
+obj-${CONFIG_MACH_TEGRA_DT} += board-seaboard-pinmux.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice.o
obj-${CONFIG_MACH_TRIMSLICE} += board-trimslice-pinmux.o
diff --git a/arch/arm/mach-tegra/board-seaboard-pinmux.c b/arch/arm/mach-tegra/board-seaboard-pinmux.c
index b31c765..b62b04d 100644
--- a/arch/arm/mach-tegra/board-seaboard-pinmux.c
+++ b/arch/arm/mach-tegra/board-seaboard-pinmux.c
@@ -158,8 +158,26 @@ static __initdata struct tegra_pingroup_config seaboard_pinmux[] = {
{TEGRA_PINGROUP_XM2D, TEGRA_MUX_NONE, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
};
-
-
+static __initdata struct tegra_pingroup_config ventana_pinmux[] = {
+ {TEGRA_PINGROUP_DAP3, TEGRA_MUX_DAP3, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_DDC, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTA, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTB, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTC, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_DTD, TEGRA_MUX_VI, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_GMD, TEGRA_MUX_SFLASH, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LPW0, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LPW2, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSC1, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_LSCK, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_LSDA, TEGRA_MUX_RSVD4, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_PTA, TEGRA_MUX_RSVD2, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXC, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SLXK, TEGRA_MUX_SDIO3, TEGRA_PUPD_NORMAL, TEGRA_TRI_NORMAL},
+ {TEGRA_PINGROUP_SPIA, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIC, TEGRA_MUX_GMI, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+ {TEGRA_PINGROUP_SPIG, TEGRA_MUX_SPI2_ALT, TEGRA_PUPD_NORMAL, TEGRA_TRI_TRISTATE},
+};
static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_SD2_CD, .enable = true },
@@ -172,6 +190,26 @@ static struct tegra_gpio_table common_gpio_table[] = {
{ .gpio = TEGRA_GPIO_USB1, .enable = true },
};
+static void __init update_pinmux(struct tegra_pingroup_config *newtbl, int size)
+{
+ int i, j;
+ struct tegra_pingroup_config *new_pingroup, *base_pingroup;
+
+ /* Update base seaboard pinmux table with secondary board
+ * specific pinmux table table.
+ */
+ for (i = 0; i < size; i++) {
+ new_pingroup = &newtbl[i];
+ for (j = 0; j < ARRAY_SIZE(seaboard_pinmux); j++) {
+ base_pingroup = &seaboard_pinmux[j];
+ if (new_pingroup->pingroup == base_pingroup->pingroup) {
+ *base_pingroup = *new_pingroup;
+ break;
+ }
+ }
+ }
+}
+
static void __init seaboard_common_pinmux_init(void)
{
tegra_pinmux_config_table(seaboard_pinmux, ARRAY_SIZE(seaboard_pinmux));
@@ -186,3 +224,10 @@ void __init seaboard_pinmux_init(void)
{
seaboard_common_pinmux_init();
}
+
+void __init ventana_pinmux_init(void)
+{
+ update_pinmux(ventana_pinmux, ARRAY_SIZE(ventana_pinmux));
+ seaboard_common_pinmux_init();
+}
+
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2 3/3] arm/tegra: device tree support for ventana board
From: Peter De Schrijver @ 2011-09-27 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143421-27286-1-git-send-email-pdeschrijver@nvidia.com>
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++++++++++++++++++++++++++++++
arch/arm/mach-tegra/Kconfig | 6 ++++++
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 5 ++++-
4 files changed, 43 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
diff --git a/arch/arm/boot/dts/tegra-ventana.dts b/arch/arm/boot/dts/tegra-ventana.dts
new file mode 100644
index 0000000..9b29a62
--- /dev/null
+++ b/arch/arm/boot/dts/tegra-ventana.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ "tegra20.dtsi"
+
+/ {
+ model = "NVIDIA Tegra2 Ventana evaluation board";
+ compatible = "nvidia,ventana", "nvidia,tegra20";
+
+ chosen {
+ bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/ram rdinit=/sbin/init";
+ };
+
+ memory {
+ reg = < 0x00000000 0x40000000 >;
+ };
+
+ serial at 70006300 {
+ clock-frequency = < 216000000 >;
+ };
+
+ sdhci at c8000400 {
+ cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+ wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+ power-gpios = <&gpio 155 0>; /* gpio PT3 */
+ };
+
+ sdhci at c8000600 {
+ power-gpios = <&gpio 70 0>; /* gpio PI6 */
+ support-8bit;
+ };
+};
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index d82ebab..91aff7c 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -69,6 +69,12 @@ config MACH_WARIO
help
Support for the Wario version of Seaboard
+config MACH_VENTANA
+ bool "Ventana board"
+ select MACH_TEGRA_DT
+ help
+ Support for the nVidia Ventana development platform
+
choice
prompt "Low-level debug console UART"
default TEGRA_DEBUG_UART_NONE
diff --git a/arch/arm/mach-tegra/Makefile.boot b/arch/arm/mach-tegra/Makefile.boot
index 5e870d2..bd12c9f 100644
--- a/arch/arm/mach-tegra/Makefile.boot
+++ b/arch/arm/mach-tegra/Makefile.boot
@@ -4,3 +4,4 @@ initrd_phys-$(CONFIG_ARCH_TEGRA_2x_SOC) := 0x00800000
dtb-$(CONFIG_MACH_HARMONY) += tegra-harmony.dtb
dtb-$(CONFIG_MACH_SEABOARD) += tegra-seaboard.dtb
+dtb-$(CONFIG_MACH_VENTANA) += tegra-ventana.dtb
diff --git a/arch/arm/mach-tegra/board-dt.c b/arch/arm/mach-tegra/board-dt.c
index 9f47e04..5885102 100644
--- a/arch/arm/mach-tegra/board-dt.c
+++ b/arch/arm/mach-tegra/board-dt.c
@@ -47,7 +47,7 @@
void harmony_pinmux_init(void);
void seaboard_pinmux_init(void);
-
+void ventana_pinmux_init(void);
struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("nvidia,tegra20-sdhci", TEGRA_SDMMC1_BASE, "sdhci-tegra.0", NULL),
@@ -95,6 +95,8 @@ static void __init tegra_dt_init(void)
harmony_pinmux_init();
else if (of_machine_is_compatible("nvidia,seaboard"))
seaboard_pinmux_init();
+ else if (of_machine_is_compatible("nvidia,ventana"))
+ ventana_pinmux_init();
/*
* Finished with the static registrations now; fill in the missing
@@ -106,6 +108,7 @@ static void __init tegra_dt_init(void)
static const char * tegra_dt_board_compat[] = {
"nvidia,harmony",
"nvidia,seaboard",
+ "nvidia,ventana",
NULL
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH V7 0/4] cpuidle: Global registration of idle states with per-cpu statistics
From: Kevin Hilman @ 2011-09-27 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110927100202.16043.58669.stgit@localhost6.localdomain6>
Deepthi Dharwar <deepthi@linux.vnet.ibm.com> writes:
> Version 6 of this patch series dated 22nd Sept 2011 was
> Acked-by: Arjan van de Ven <arjan@linux.intel.com>
> Acked-by: Kevin Hilman <khilman@ti.com> for OMAP specific parts.
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
minor: I think this should be a Tested-by from Jean. Since he was not on
the delivery path, it should not be a sign-off.
Kevin
^ permalink raw reply
* [PATCH v3 0/6] OMAP: omap_device cleanup before device-tree integration
From: Benoit Cousson @ 2011-09-27 17:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kevin,
Here are a couple of cleanups on top of your for_3.2/omap_device branch.
patches are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/1_omap_device_cleanup
Regards,
Benoit
Changes since v1: http://www.spinics.net/lists/linux-omap/msg55801.html
- Update the 2 patches from Nishanth based on Kevin's comment and merge
them into one patch.
- Fix the omap_device_pm_latency issue reported by Paul.
Changes since v2: http://www.spinics.net/lists/arm-kernel/msg138993.html
- Change the API name from omap_hwmod_name_get_dev to
omap_device_get_by_hwmod_name per Kevin's suggestion.
Benoit Cousson (5):
OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API
OMAP2+: pm: Use hwmod name instead of dev pointer
OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM
OMAP: omap_device: Create a default omap_device_pm_latency
OMAP2+: devices: Remove all omap_device_pm_latency structures
Nishanth Menon (1):
OMAP: omap_device: Add omap_device_get_by_hwmod_name
arch/arm/mach-omap2/board-omap3beagle.c | 4 +-
arch/arm/mach-omap2/devices.c | 46 ++---------------
arch/arm/mach-omap2/display.c | 11 +----
arch/arm/mach-omap2/dma.c | 11 +----
arch/arm/mach-omap2/gpio.c | 12 +----
arch/arm/mach-omap2/hsmmc.c | 18 +------
arch/arm/mach-omap2/hwspinlock.c | 12 +----
arch/arm/mach-omap2/mcbsp.c | 11 +----
arch/arm/mach-omap2/pm.c | 69 ++++++++-----------------
arch/arm/mach-omap2/serial.c | 25 +---------
arch/arm/mach-omap2/sr_device.c | 11 +----
arch/arm/mach-omap2/usb-musb.c | 11 +----
arch/arm/plat-omap/i2c.c | 10 +---
arch/arm/plat-omap/include/plat/omap_device.h | 1 +
arch/arm/plat-omap/omap_device.c | 55 +++++++++++++++++++-
15 files changed, 93 insertions(+), 214 deletions(-)
^ permalink raw reply
* [PATCH v3 1/6] OMAP: omap_device: Add omap_device_get_by_hwmod_name
From: Benoit Cousson @ 2011-09-27 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143886-13285-1-git-send-email-b-cousson@ti.com>
From: Nishanth Menon <nm@ti.com>
An API which translates a standard hwmod name to corresponding
platform_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like "gpu" instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.
Signed-off-by: Nishanth Menon <nm@ti.com>
[b-cousson at ti.com: Adapt it to the new pdev pointer inside od,
remove the unneeded helpers, and fold the next patch here]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
---
arch/arm/plat-omap/include/plat/omap_device.h | 1 +
arch/arm/plat-omap/omap_device.c | 36 +++++++++++++++++++++++++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index d4d9b96..12c5b0c 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -101,6 +101,7 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
int pm_lats_cnt, int is_early_device);
void __iomem *omap_device_get_rt_va(struct omap_device *od);
+struct device *omap_device_get_by_hwmod_name(const char *oh_name);
/* OMAP PM interface */
int omap_device_align_pm_lat(struct platform_device *pdev,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 26aee5c..f832f92 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -844,6 +844,42 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od)
return omap_hwmod_get_mpu_rt_va(od->hwmods[0]);
}
+/**
+ * omap_device_get_by_hwmod_name() - convert a hwmod name to
+ * device pointer.
+ * @oh_name: name of the hwmod device
+ *
+ * Returns back a struct device * pointer associated with a hwmod
+ * device represented by a hwmod_name
+ */
+struct device *omap_device_get_by_hwmod_name(const char *oh_name)
+{
+ struct omap_hwmod *oh;
+
+ if (!oh_name) {
+ WARN(1, "%s: no hwmod name!\n", __func__);
+ return ERR_PTR(-EINVAL);
+ }
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (IS_ERR_OR_NULL(oh)) {
+ WARN(1, "%s: no hwmod for %s\n", __func__,
+ oh_name);
+ return ERR_PTR(oh ? PTR_ERR(oh) : -ENODEV);
+ }
+ if (IS_ERR_OR_NULL(oh->od)) {
+ WARN(1, "%s: no omap_device for %s\n", __func__,
+ oh_name);
+ return ERR_PTR(oh->od ? PTR_ERR(oh->od) : -ENODEV);
+ }
+
+ if (IS_ERR_OR_NULL(oh->od->pdev))
+ return ERR_PTR(oh->od->pdev ? PTR_ERR(oh->od->pdev) : -ENODEV);
+
+ return &oh->od->pdev->dev;
+}
+EXPORT_SYMBOL(omap_device_get_by_hwmod_name);
+
/*
* Public functions intended for use in omap_device_pm_latency
* .activate_func and .deactivate_func function pointers
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 2/6] OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API
From: Benoit Cousson @ 2011-09-27 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143886-13285-1-git-send-email-b-cousson@ti.com>
Replace the multiple omap2_get_XXX_device APIs with the new
omap_hwmod_name_get_dev that uses the hwmod name to get the proper
device.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 3ae16b4..9815b2b 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -493,8 +493,8 @@ static void __init beagle_opp_init(void)
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
- mpu_dev = omap2_get_mpuss_device();
- iva_dev = omap2_get_iva_device();
+ mpu_dev = omap_device_get_by_hwmod_name("mpu");
+ iva_dev = omap_device_get_by_hwmod_name("iva");
if (!mpu_dev || !iva_dev) {
pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 3/6] OMAP2+: pm: Use hwmod name instead of dev pointer
From: Benoit Cousson @ 2011-09-27 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143886-13285-1-git-send-email-b-cousson@ti.com>
Replace the struct device parameter of omap2_set_init_voltage
by the hwmod name. It will avoid having to store explicitely
the device pointer into a static variable.
Moreover, it will be a little bit more scalable if we introduce
new DVFS devices.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/pm.c | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index e7cd794..f852e4f 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -169,18 +169,26 @@ err:
* in the opp entry
*/
static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
- struct device *dev)
+ const char *oh_name)
{
struct voltagedomain *voltdm;
struct clk *clk;
struct opp *opp;
unsigned long freq, bootup_volt;
+ struct device *dev;
- if (!vdd_name || !clk_name || !dev) {
+ if (!vdd_name || !clk_name || !oh_name) {
printk(KERN_ERR "%s: Invalid parameters!\n", __func__);
goto exit;
}
+ dev = omap_device_get_by_hwmod_name(oh_name);
+ if (IS_ERR(dev)) {
+ pr_err("%s: Unable to get dev pointer for hwmod %s\n",
+ __func__, oh_name);
+ goto exit;
+ }
+
voltdm = omap_voltage_domain_lookup(vdd_name);
if (IS_ERR(voltdm)) {
printk(KERN_ERR "%s: Unable to get vdd pointer for vdd_%s\n",
@@ -226,8 +234,8 @@ static void __init omap3_init_voltages(void)
if (!cpu_is_omap34xx())
return;
- omap2_set_init_voltage("mpu", "dpll1_ck", mpu_dev);
- omap2_set_init_voltage("core", "l3_ick", l3_dev);
+ omap2_set_init_voltage("mpu", "dpll1_ck", "mpu");
+ omap2_set_init_voltage("core", "l3_ick", "l3_main");
}
static void __init omap4_init_voltages(void)
@@ -235,9 +243,9 @@ static void __init omap4_init_voltages(void)
if (!cpu_is_omap44xx())
return;
- omap2_set_init_voltage("mpu", "dpll_mpu_ck", mpu_dev);
- omap2_set_init_voltage("core", "l3_div_ck", l3_dev);
- omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", iva_dev);
+ omap2_set_init_voltage("mpu", "dpll_mpu_ck", "mpu");
+ omap2_set_init_voltage("core", "l3_div_ck", "l3_main_1");
+ omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", "iva");
}
static int __init omap2_common_pm_init(void)
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 4/6] OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM
From: Benoit Cousson @ 2011-09-27 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143886-13285-1-git-send-email-b-cousson@ti.com>
Since the device pointer is now retrieved using the hwmod name, remove
the static variables used to store the device pointers for DSP, MPU, IVA
and L3 devices for PM/DVFS usage.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/pm.c | 47 ++++++---------------------------------------
1 files changed, 7 insertions(+), 40 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index f852e4f..d2ef1c2 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -26,38 +26,7 @@
static struct omap_device_pm_latency *pm_lats;
-static struct device *mpu_dev;
-static struct device *iva_dev;
-static struct device *l3_dev;
-static struct device *dsp_dev;
-
-struct device *omap2_get_mpuss_device(void)
-{
- WARN_ON_ONCE(!mpu_dev);
- return mpu_dev;
-}
-
-struct device *omap2_get_iva_device(void)
-{
- WARN_ON_ONCE(!iva_dev);
- return iva_dev;
-}
-
-struct device *omap2_get_l3_device(void)
-{
- WARN_ON_ONCE(!l3_dev);
- return l3_dev;
-}
-
-struct device *omap4_get_dsp_device(void)
-{
- WARN_ON_ONCE(!dsp_dev);
- return dsp_dev;
-}
-EXPORT_SYMBOL(omap4_get_dsp_device);
-
-/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
-static int _init_omap_device(char *name, struct device **new_dev)
+static int _init_omap_device(char *name)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -72,8 +41,6 @@ static int _init_omap_device(char *name, struct device **new_dev)
__func__, name))
return -ENODEV;
- *new_dev = &pdev->dev;
-
return 0;
}
@@ -82,16 +49,16 @@ static int _init_omap_device(char *name, struct device **new_dev)
*/
static void omap2_init_processor_devices(void)
{
- _init_omap_device("mpu", &mpu_dev);
+ _init_omap_device("mpu");
if (omap3_has_iva())
- _init_omap_device("iva", &iva_dev);
+ _init_omap_device("iva");
if (cpu_is_omap44xx()) {
- _init_omap_device("l3_main_1", &l3_dev);
- _init_omap_device("dsp", &dsp_dev);
- _init_omap_device("iva", &iva_dev);
+ _init_omap_device("l3_main_1");
+ _init_omap_device("dsp");
+ _init_omap_device("iva");
} else {
- _init_omap_device("l3_main", &l3_dev);
+ _init_omap_device("l3_main");
}
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 5/6] OMAP: omap_device: Create a default omap_device_pm_latency
From: Benoit Cousson @ 2011-09-27 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143886-13285-1-git-send-email-b-cousson@ti.com>
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.
Next patches will clean the duplicated structures.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
arch/arm/plat-omap/omap_device.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index f832f92..cd8d977 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -97,6 +97,14 @@
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
+static struct omap_device_pm_latency omap_default_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
/* Private functions */
/**
@@ -510,8 +518,17 @@ struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
if (ret)
goto odbs_exit3;
- od->pm_lats = pm_lats;
+ if (!pm_lats) {
+ pm_lats = omap_default_latency;
+ pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+ }
+
od->pm_lats_cnt = pm_lats_cnt;
+ od->pm_lats = kmemdup(pm_lats,
+ sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
+ GFP_KERNEL);
+ if (!od->pm_lats)
+ goto odbs_exit3;
for (i = 0; i < oh_cnt; i++) {
hwmods[i]->od = od;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 6/6] OMAP2+: devices: Remove all omap_device_pm_latency structures
From: Benoit Cousson @ 2011-09-27 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143886-13285-1-git-send-email-b-cousson@ti.com>
Remove all these duplicated structures since a default one is now
available.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/devices.c | 46 +++----------------------------------
arch/arm/mach-omap2/display.c | 11 +--------
arch/arm/mach-omap2/dma.c | 11 +--------
arch/arm/mach-omap2/gpio.c | 12 +---------
arch/arm/mach-omap2/hsmmc.c | 18 +--------------
arch/arm/mach-omap2/hwspinlock.c | 12 +---------
arch/arm/mach-omap2/mcbsp.c | 11 +--------
arch/arm/mach-omap2/serial.c | 25 +-------------------
arch/arm/mach-omap2/sr_device.c | 11 +--------
arch/arm/mach-omap2/usb-musb.c | 11 +--------
arch/arm/plat-omap/i2c.c | 10 +-------
11 files changed, 14 insertions(+), 164 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 10adf66..2d4a199 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -221,14 +221,6 @@ static inline void omap_init_camera(void)
#endif
}
-struct omap_device_pm_latency omap_keyboard_latency[] = {
- {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
{
@@ -248,9 +240,7 @@ int __init omap4_keyboard_init(struct omap4_keypad_platform_data
keypad_data = sdp4430_keypad_data;
pdev = omap_device_build(name, id, oh, keypad_data,
- sizeof(struct omap4_keypad_platform_data),
- omap_keyboard_latency,
- ARRAY_SIZE(omap_keyboard_latency), 0);
+ sizeof(struct omap4_keypad_platform_data), NULL, 0, 0);
if (IS_ERR(pdev)) {
WARN(1, "Can't build omap_device for %s:%s.\n",
@@ -263,14 +253,6 @@ int __init omap4_keyboard_init(struct omap4_keypad_platform_data
}
#if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-static struct omap_device_pm_latency mbox_latencies[] = {
- [0] = {
- .activate_func = omap_device_enable_hwmods,
- .deactivate_func = omap_device_idle_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static inline void omap_init_mbox(void)
{
struct omap_hwmod *oh;
@@ -282,8 +264,7 @@ static inline void omap_init_mbox(void)
return;
}
- pdev = omap_device_build("omap-mailbox", -1, oh, NULL, 0,
- mbox_latencies, ARRAY_SIZE(mbox_latencies), 0);
+ pdev = omap_device_build("omap-mailbox", -1, oh, NULL, 0, NULL, 0, 0);
WARN(IS_ERR(pdev), "%s: could not build device, err %ld\n",
__func__, PTR_ERR(pdev));
}
@@ -334,14 +315,6 @@ static inline void omap_init_audio(void) {}
#include <plat/mcspi.h>
-struct omap_device_pm_latency omap_mcspi_latency[] = {
- [0] = {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static int omap_mcspi_init(struct omap_hwmod *oh, void *unused)
{
struct platform_device *pdev;
@@ -372,8 +345,7 @@ static int omap_mcspi_init(struct omap_hwmod *oh, void *unused)
spi_num++;
pdev = omap_device_build(name, spi_num, oh, pdata,
- sizeof(*pdata), omap_mcspi_latency,
- ARRAY_SIZE(omap_mcspi_latency), 0);
+ sizeof(*pdata), NULL, 0, 0);
WARN(IS_ERR(pdev), "Can't build omap_device for %s:%s\n",
name, oh->name);
kfree(pdata);
@@ -698,14 +670,6 @@ static int __init omap2_init_devices(void)
arch_initcall(omap2_init_devices);
#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-static struct omap_device_pm_latency omap_wdt_latency[] = {
- [0] = {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static int __init omap_init_wdt(void)
{
int id = -1;
@@ -723,9 +687,7 @@ static int __init omap_init_wdt(void)
return -EINVAL;
}
- pdev = omap_device_build(dev_name, id, oh, NULL, 0,
- omap_wdt_latency,
- ARRAY_SIZE(omap_wdt_latency), 0);
+ pdev = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);
WARN(IS_ERR(pdev), "Can't build omap_device for %s:%s.\n",
dev_name, oh->name);
return 0;
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 18693f6..8ad0a2f 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -35,14 +35,6 @@ static struct platform_device omap_display_device = {
},
};
-static struct omap_device_pm_latency omap_dss_latency[] = {
- [0] = {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
struct omap_dss_hwmod_data {
const char *oh_name;
const char *dev_name;
@@ -111,8 +103,7 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)
pdev = omap_device_build(curr_dss_hwmod[i].dev_name,
curr_dss_hwmod[i].id, oh, &pdata,
sizeof(struct omap_display_platform_data),
- omap_dss_latency,
- ARRAY_SIZE(omap_dss_latency), 0);
+ NULL, 0, 0);
if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",
curr_dss_hwmod[i].oh_name))
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index ae8cb3f..a59a45a 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -87,14 +87,6 @@ static u16 reg_map[] = {
[CCDN] = 0xd8,
};
-static struct omap_device_pm_latency omap2_dma_latency[] = {
- {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static void __iomem *dma_base;
static inline void dma_write(u32 val, int reg, int lch)
{
@@ -258,8 +250,7 @@ static int __init omap2_system_dma_init_dev(struct omap_hwmod *oh, void *unused)
p->errata = configure_dma_errata();
- pdev = omap_device_build(name, 0, oh, p, sizeof(*p),
- omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
+ pdev = omap_device_build(name, 0, oh, p, sizeof(*p), NULL, 0, 0);
kfree(p);
if (IS_ERR(pdev)) {
pr_err("%s: Can't build omap_device for %s:%s.\n",
diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index 652ccc5..8cbfbc2 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -24,14 +24,6 @@
#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
-static struct omap_device_pm_latency omap_gpio_latency[] = {
- [0] = {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
{
struct platform_device *pdev;
@@ -108,9 +100,7 @@ static int omap2_gpio_dev_init(struct omap_hwmod *oh, void *unused)
}
pdev = omap_device_build(name, id - 1, oh, pdata,
- sizeof(*pdata), omap_gpio_latency,
- ARRAY_SIZE(omap_gpio_latency),
- false);
+ sizeof(*pdata), NULL, 0, false);
kfree(pdata);
if (IS_ERR(pdev)) {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index cc87919..fe16da4 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -413,31 +413,17 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c,
return 0;
}
-static struct omap_device_pm_latency omap_hsmmc_latency[] = {
- [0] = {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
- /*
- * XXX There should also be an entry here to power off/on the
- * MMC regulators/PBIAS cells, etc.
- */
-};
-
#define MAX_OMAP_MMC_HWMOD_NAME_LEN 16
void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
- struct omap_device_pm_latency *ohl;
char oh_name[MAX_OMAP_MMC_HWMOD_NAME_LEN];
struct omap_mmc_platform_data *mmc_data;
struct omap_mmc_dev_attr *mmc_dev_attr;
char *name;
int l;
- int ohl_cnt = 0;
mmc_data = kzalloc(sizeof(struct omap_mmc_platform_data), GFP_KERNEL);
if (!mmc_data) {
@@ -452,8 +438,6 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
omap_hsmmc_mux(mmc_data, (ctrl_nr - 1));
name = "omap_hsmmc";
- ohl = omap_hsmmc_latency;
- ohl_cnt = ARRAY_SIZE(omap_hsmmc_latency);
l = snprintf(oh_name, MAX_OMAP_MMC_HWMOD_NAME_LEN,
"mmc%d", ctrl_nr);
@@ -472,7 +456,7 @@ void __init omap_init_hsmmc(struct omap2_hsmmc_info *hsmmcinfo, int ctrl_nr)
}
pdev = omap_device_build(name, ctrl_nr - 1, oh, mmc_data,
- sizeof(struct omap_mmc_platform_data), ohl, ohl_cnt, false);
+ sizeof(struct omap_mmc_platform_data), NULL, 0, false);
if (IS_ERR(pdev)) {
WARN(1, "Can't build omap_device for %s:%s.\n", name, oh->name);
kfree(mmc_data->slots[0].name);
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
index 0b3ae9d..36e2109 100644
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ b/arch/arm/mach-omap2/hwspinlock.c
@@ -23,14 +23,6 @@
#include <plat/omap_hwmod.h>
#include <plat/omap_device.h>
-struct omap_device_pm_latency omap_spinlock_latency[] = {
- {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- }
-};
-
int __init hwspinlocks_init(void)
{
int retval = 0;
@@ -48,9 +40,7 @@ int __init hwspinlocks_init(void)
if (oh == NULL)
return -EINVAL;
- pdev = omap_device_build(dev_name, 0, oh, NULL, 0,
- omap_spinlock_latency,
- ARRAY_SIZE(omap_spinlock_latency), false);
+ pdev = omap_device_build(dev_name, 0, oh, NULL, 0, NULL, 0, false);
if (IS_ERR(pdev)) {
pr_err("Can't build omap_device for %s:%s\n", dev_name,
oh_name);
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7a42f32..9fb5d7d 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -102,14 +102,6 @@ int omap2_mcbsp_set_clks_src(u8 id, u8 fck_src_id)
}
EXPORT_SYMBOL(omap2_mcbsp_set_clks_src);
-struct omap_device_pm_latency omap2_mcbsp_latency[] = {
- {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
{
int id, count = 1;
@@ -145,8 +137,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void *unused)
count++;
}
pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
- sizeof(*pdata), omap2_mcbsp_latency,
- ARRAY_SIZE(omap2_mcbsp_latency), false);
+ sizeof(*pdata), NULL, 0, false);
kfree(pdata);
if (IS_ERR(pdev)) {
pr_err("%s: Can't build omap_device for %s:%s.\n", __func__,
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3d1c1d3..9992dbf 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -107,28 +107,6 @@ struct omap_uart_state {
static LIST_HEAD(uart_list);
static u8 num_uarts;
-static int uart_idle_hwmod(struct omap_device *od)
-{
- omap_hwmod_idle(od->hwmods[0]);
-
- return 0;
-}
-
-static int uart_enable_hwmod(struct omap_device *od)
-{
- omap_hwmod_enable(od->hwmods[0]);
-
- return 0;
-}
-
-static struct omap_device_pm_latency omap_uart_latency[] = {
- {
- .deactivate_func = uart_idle_hwmod,
- .activate_func = uart_enable_hwmod,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static inline unsigned int __serial_read_reg(struct uart_port *up,
int offset)
{
@@ -800,8 +778,7 @@ void __init omap_serial_init_port(struct omap_board_data *bdata)
return;
pdev = omap_device_build(name, uart->num, oh, pdata, pdata_size,
- omap_uart_latency,
- ARRAY_SIZE(omap_uart_latency), false);
+ NULL, 0, false);
WARN(IS_ERR(pdev), "Could not build omap_device for %s: %s.\n",
name, oh->name);
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index 624264d..3b5cf50 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -31,14 +31,6 @@
static bool sr_enable_on_init;
-static struct omap_device_pm_latency omap_sr_latency[] = {
- {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST
- },
-};
-
/* Read EFUSE values from control registers for OMAP3430 */
static void __init sr_set_nvalues(struct omap_volt_data *volt_data,
struct omap_sr_data *sr_data)
@@ -121,8 +113,7 @@ static int sr_dev_init(struct omap_hwmod *oh, void *user)
sr_data->enable_on_init = sr_enable_on_init;
pdev = omap_device_build(name, i, oh, sr_data, sizeof(*sr_data),
- omap_sr_latency,
- ARRAY_SIZE(omap_sr_latency), 0);
+ NULL, 0, 0);
if (IS_ERR(pdev))
pr_warning("%s: Could not build omap_device for %s: %s.\n\n",
__func__, name, oh->name);
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index a65145b..c13ff3f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -60,14 +60,6 @@ static struct musb_hdrc_platform_data musb_plat = {
static u64 musb_dmamask = DMA_BIT_MASK(32);
-static struct omap_device_pm_latency omap_musb_latency[] = {
- {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static void usb_musb_mux_init(struct omap_musb_board_data *board_data)
{
switch (board_data->interface_type) {
@@ -155,8 +147,7 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
}
od = omap_device_build(name, bus_id, oh, &musb_plat,
- sizeof(musb_plat), omap_musb_latency,
- ARRAY_SIZE(omap_musb_latency), false);
+ sizeof(musb_plat), NULL, 0, false);
if (IS_ERR(od)) {
pr_err("Could not build omap_device for %s %s\n",
name, oh_name);
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 0c7caf2..c20beb8 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -123,14 +123,6 @@ static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
omap_pm_set_max_mpu_wakeup_lat(dev, t);
}
-static struct omap_device_pm_latency omap_i2c_latency[] = {
- [0] = {
- .deactivate_func = omap_device_idle_hwmods,
- .activate_func = omap_device_enable_hwmods,
- .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
- },
-};
-
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
@@ -162,7 +154,7 @@ static inline int omap2_i2c_add_bus(int bus_id)
pdata->set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
- omap_i2c_latency, ARRAY_SIZE(omap_i2c_latency), 0);
+ NULL, 0, 0);
WARN(IS_ERR(pdev), "Could not build omap_device for %s\n", name);
return PTR_ERR(pdev);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 5/6] OMAP: omap_device: Create a default omap_device_pm_latency
From: Tony Lindgren @ 2011-09-27 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143886-13285-6-git-send-email-b-cousson@ti.com>
* Benoit Cousson <b-cousson@ti.com> [110927 09:45]:
> Most devices are using the same default omap_device_pm_latency structure
> during device built. In order to avoid the duplication of the same
> structure everywhere, add a default structure that will be used if
> the device does not have an explicit one.
>
> Next patches will clean the duplicated structures.
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
> arch/arm/plat-omap/omap_device.c | 19 ++++++++++++++++++-
> 1 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> index f832f92..cd8d977 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -97,6 +97,14 @@
> static int omap_device_register(struct platform_device *pdev);
> static int omap_early_device_register(struct platform_device *pdev);
>
> +static struct omap_device_pm_latency omap_default_latency[] = {
> + {
> + .deactivate_func = omap_device_idle_hwmods,
> + .activate_func = omap_device_enable_hwmods,
> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> + }
> +};
> +
> /* Private functions */
Isn't this racey between devices if the latency values get adjusted
automatically for each device?
Tony
^ permalink raw reply
* [PATCH v2 2/3] arm/tegra: add support for ventana pinmuxing
From: Olof Johansson @ 2011-09-27 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317143421-27286-3-git-send-email-pdeschrijver@nvidia.com>
Hi,
The series looks reasonable to me, I'll apply it together with some of
the other pending tegra patches from the list. Once Stephen's pinmux
devicetree code is in place some of this can be removed.
One comment on this patch description though:
On Tue, Sep 27, 2011 at 10:10 AM, Peter De Schrijver
<pdeschrijver@nvidia.com> wrote:
> Add support for ventana pinmuxing as a seaboard derivative. This is a cut down
> version of chromeos kernel commit 772f1b56e713be7a55759c2d5eadb9eb11d078db
> by Jong Kim <jongk@nvidia.com>.
Having a reference to a SHA1 in a foreign source tree isn't really
useful in the mainline kernel commit log.
I would just phrase it "This is a cut down version of work done by <....>"
-Olof
^ permalink raw reply
* try_to_freeze() called with IRQs disabled on ARM
From: Ulrich Weigand @ 2011-09-27 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110902174812.GD6619@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> And yes, we can end up processing the interrupt before the SVC is
> executed, which is still a hole. So we need to avoid doing the
> restart in userspace - which might actually make things easier.
> I'll take a look into that over the weekend.
Hi Russell, I was wondering whether is there any news on this?
If you do rewrite the signal handler processing, please let me
know so I can update GDB accordingly ... Thanks!
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Gesch?ftsf?hrung: Dirk
Wittkopp
Sitz der Gesellschaft: B?blingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
^ permalink raw reply
* [RFC PATCH 0/3] Add accurate boot timing to a Linux system
From: Tim Bird @ 2011-09-27 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316818998-30711-1-git-send-email-sjg@chromium.org>
On 09/23/2011 04:03 PM, Simon Glass wrote:
> This experimental patch set adds boot timing to a Linux system. The
> timing starts with the boot loader and extends through the kernel into
> user space to the completion of the boot process. The timing starts when
> the system leaves reset, not later when the kernel starts.
I would be very interested in this. This is something that
would be very helpful, I believe, to assist with optimizing
overall boot time.
> Finally, in user space there is no kernel-blessed way to record
> timestamps. One approach is to add lines to the init scripts like
> 'cat /proc/uptime >/tmp/login_starts'.
> This creates another place where
> the boot timing tool must look for information.
'cat /proc/uptime >/dev/kmsg' (with printk timestamps on) is much
better than the above, for this reason.
> This Patchset
> -------------
> This patchset aims to unify timing in one place: a simple driver which
> collects pre-kernel boot timestamps, adds its own as it boots, with
> calls to bootstage_mark(), then allows user space (init, etc.) to add
> more with 'echo "message" >>/sys/kernel/debug/bootstage/mask'.
>
> Finally it permits user space to access the full list of timestamps
> with 'cat /sys/kernel/debug/bootstage/report', which has two columns:
> the stage name and the timestamp:
>
> reset 0
> arch_cpu_init-AVP 258902
> arch_cpu_init-A9 263267
> arch_cpu_init-done 263312
> board_init_f-start 263314
> board_init_r-start 323671
> main_loop 573008
...
I would prefer the timestamp in the first column. Also, for consistency
it would be good if it used the same format as printk timestamps:
"[%5lu.%06lu]" with seconds and micro-seconds in the respective fields.
Then, existing tools like scripts/show_delta and scripts/bootgraph.pl
could work on this data as well.
Full micro-second granularity is not required, but it's nice to keep
the format the same, whether the clock supports it or not.
Finally, is this work related at all to this:
http://lists.denx.de/pipermail/u-boot/2011-September/099996.html
Bootgraph.pl instrumentation support for UBoot
??
Just wondering.
Thanks - this looks like great stuff!
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
^ permalink raw reply
* [RFC PATCH 0/3] Add accurate boot timing to a Linux system
From: Tim Bird @ 2011-09-27 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E820E4D.5050205@am.sony.com>
Sorry for the dup. Mailer freaking out.
My apologies...
-- Tim
^ permalink raw reply
* [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
From: Laurent Pinchart @ 2011-09-27 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19F8576C6E063C45BE387C64729E739404EC8113E2@dbde02.ent.ti.com>
Hi Vaibhav,
On Monday 19 September 2011 17:31:02 Hiremath, Vaibhav wrote:
> On Friday, September 16, 2011 6:36 PM Laurent Pinchart wrote:
> > On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
> > > On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
> > > > On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
> > > >> From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > >>
> > > >> In order to support TVP5146 (for that matter any video decoder),
> > > >> it is important to support G/S/ENUM_STD ioctl on /dev/videoX
> > > >> device node.
> > > >
> > > > Why so ? Shouldn't it be queried on the subdev output pad directly ?
> > >
> > > Because standard v4l2 application for analog devices will call these
> > > std ioctls on the streaming device node. So it's done on /dev/video to
> > > make the existing apllication work.
> >
> > Existing applications can't work with the OMAP3 ISP (and similar complex
> > embedded devices) without userspace support anyway, either in the form of
> > a GStreamer element or a libv4l plugin. I still believe that analog video
> > standard operations should be added to the subdev pad operations and
> > exposed through subdev device nodes, exactly as done with formats.
>
> I completely agree with your point that, existing application will not work
> without setting links properly. But I believe the assumption here is,
> media-controller should set the links (along with pad formants) and all
> existing application should work as is. Isn't it?
The media controller is an API used (among other things) to set the links. You
still need to call it from userspace. That won't happen magically. The
userspace component that sets up the links and configures the formats, be it a
GStreamer element, a libv4l plugin, or something else, can as well setup the
standard on the TVP5146 subdev.
> The way it is being done currently is, set the format at the pad level
> which is same as analog standard resolution and use existing application
> for streaming...
At then end of the OMAP3 ISP pipeline video data has long lost its analog
roots. I don't think standards make sense there.
> I am ok, if we add s/g/enum_std api support at sub-dev level but this
> should also be supported on streaming device node.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 2/3] arm/tegra: add support for ventana pinmuxing
From: Peter De Schrijver @ 2011-09-27 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjqhGYUQ2XmuBBTBSUA6mKnOLF=Hmi86hRQhLiUMPtiBg@mail.gmail.com>
On Tue, Sep 27, 2011 at 07:36:24PM +0200, Olof Johansson wrote:
> Hi,
>
> The series looks reasonable to me, I'll apply it together with some of
> the other pending tegra patches from the list. Once Stephen's pinmux
> devicetree code is in place some of this can be removed.
>
> One comment on this patch description though:
>
>
> On Tue, Sep 27, 2011 at 10:10 AM, Peter De Schrijver
> <pdeschrijver@nvidia.com> wrote:
> > Add support for ventana pinmuxing as a seaboard derivative. This is a cut down
> > version of chromeos kernel commit 772f1b56e713be7a55759c2d5eadb9eb11d078db
> > by Jong Kim <jongk@nvidia.com>.
>
> Having a reference to a SHA1 in a foreign source tree isn't really
> useful in the mainline kernel commit log.
>
> I would just phrase it "This is a cut down version of work done by <....>"
>
Ok. I will resend this series with the updated description.
Cheers,
Peter.
^ 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