Re: [PATCH 1/3] clk: introduce omap_clk_associate
"ext Tony Lindgren" <[EMAIL PROTECTED]> writes: > * Igor Stoppa <[EMAIL PROTECTED]> [081014 14:12]: >> On Tue, 2008-10-14 at 13:59 -0700, ext Tony Lindgren wrote: >> >> > And that we can use same naming in the driver no matter which omap :) >> >> Wasn't that one of the main features of the clock FW, when it was >> designed? > > Yes. But we adding separate ick and fck during omap2420 confused > that. Why this was originally done? I mean we have possibility to autogate interface clocks. AFAIK those could be just fine be enabled on boot and let the hw to take care of them. -- Jouni Högander -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add pm-debug counters
"ext Peter 'p2' De Schrijver" <[EMAIL PROTECTED]> writes:
> This patch provides the debugfs entries and a function which will be called
> by the PM code to register the time spent per domain per state.
>
> Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/pm-debug.c| 175
> +
> arch/arm/mach-omap2/pm.h |2 +
> 2 files changed, 177 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 0b5c044..4ba6cec 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -29,6 +29,8 @@
>
> #include
> #include
> +#include
> +#include
>
> #include "prm.h"
> #include "cm.h"
> @@ -288,4 +290,177 @@ void omap2_pm_dump(int mode, int resume, unsigned int
> us)
> printk("%-20s: 0x%08x\n", regs[i].name, regs[i].val);
> }
>
> +#ifdef CONFIG_DEBUG_FS
> +#include
> +#include
> +
> +struct dentry *pm_dbg_dir;
> +
> +static int pm_dbg_init_done;
> +
> +enum {
> + DEBUG_FILE_COUNTERS = 0,
> + DEBUG_FILE_TIMERS,
> +};
> +
> +static const char pwrdm_state_names[][4] = {
> + "OFF",
> + "RET",
> + "INA",
> + "ON"
> +};
> +
> +void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
> +{
> + s64 t;
> + struct timespec now;
> +
> + if (!pm_dbg_init_done)
> + return ;
> +
> + /* Update timer for previous state */
> + getnstimeofday(&now);
> + t = timespec_to_ns(&now);
> +
> + pwrdm->state_timer[prev] += t - pwrdm->timer;
> +
> + pwrdm->timer = t;
> +}
> +
> +static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
> +{
> + struct seq_file *s = (struct seq_file *)user;
> +
> + if (strcmp(clkdm->name, "emu_clkdm") == 0 ||
> + strcmp(clkdm->name, "wkup_clkdm") == 0)
> + return 0;
Why emu and wkup are not taken into account? If wkup is closed out
here, I think also prm_clkdm and cm_clkdm should be.
> +
> + seq_printf(s, "%s->%s (%d)", clkdm->name,
> + clkdm->pwrdm.ptr->name,
> + atomic_read(&clkdm->usecount));
> + seq_printf(s, "\n");
> +
> + return 0;
> +}
> +
> +static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void *user)
> +{
> + struct seq_file *s = (struct seq_file *)user;
> + int i;
> +
> + if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
> + strcmp(pwrdm->name, "wkup_pwrdm") == 0)
> + return 0;
Why emu is closed out here? It has pwstst register. I think also
dpll1..5_pwrdm should be closed out here. I'm not sure why those are
even modelled in a clocktree.
> +
> + if (pwrdm->state != pwrdm_read_pwrst(pwrdm))
> + printk(KERN_ERR "pwrdm state mismatch(%s) %d != %d\n",
> + pwrdm->name, pwrdm->state, pwrdm_read_pwrst(pwrdm));
> +
> + seq_printf(s, "%s (%s)", pwrdm->name,
> + pwrdm_state_names[pwrdm->state]);
> + for (i = 0; i < 4; i++)
> + seq_printf(s, ",%s:%d", pwrdm_state_names[i],
> + pwrdm->state_counter[i]);
> +
> + seq_printf(s, "\n");
> +
> + return 0;
> +}
> +
> +static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user)
> +{
> + struct seq_file *s = (struct seq_file *)user;
> + int i;
> +
> + if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
> + strcmp(pwrdm->name, "wkup_pwrdm") == 0)
> + return 0;
Same comment as above.
> +
> + pwrdm_state_switch(pwrdm);
> +
> + seq_printf(s, "%s (%s)", pwrdm->name,
> + pwrdm_state_names[pwrdm->state]);
> +
> + for (i = 0; i < 4; i++)
> + seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
> + pwrdm->state_timer[i]);
> +
> + seq_printf(s, "\n");
> +
> + return 0;
> +}
> +
> +static void pm_dbg_show_counters(struct seq_file *s, void *unused)
> +{
> + pwrdm_for_each(pwrdm_dbg_show_counter, s);
> + clkdm_for_each(clkdm_dbg_show_counter, s);
> +}
> +
> +static void pm_dbg_show_timers(struct seq_file *s, void *unused)
> +{
> + pwrdm_for_each(pwrdm_dbg_show_timer, s);
> +}
> +
> +static int pm_dbg_open(struct inode *inode, struct file *file)
> +{
> + switch ((int)inode->i_private) {
> + case DEBUG_FILE_COUNTERS:
> + return single_open(file, pm_dbg_show_counters,
> + &inode->i_private);
> + case DEBUG_FILE_TIMERS:
> + default:
> + return single_open(file, pm_dbg_show_timers,
> + &inode->i_private);
> + };
> +}
> +
> +static const struct file_operations debug_fops = {
> + .open = pm_dbg_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release= single_release,
> +};
> +
> +static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> +{
> + int i;
> + s64 t;
> + struct timespec now;
> +
> +
Re: git pull request for minimal omap3 support one more time
On Tue, 14 Oct 2008 10:19:08 -0700 "ext Tony Lindgren" <[EMAIL PROTECTED]> wrote: > > Please take a look and resolve ASAP. Thanks. > > Sorry for the delay, I was sitting in an airplane again. > > Here's the fix, looks like the missing McBSP irqs should have been > merged into the recent McBSP patches. > > This patch is also in your patch system as 5301/1. > Tony, If my patch below from linux-omap was forgotten from original pull request, please note that it's required to add those rx/tx irqs into omap_mcbsp_platform_data structs in arch/arm/mach-omap2/mcbsp.c as well. Otherwise arch/arm/plat-omap/mcbsp.c: omap_mcbsp_request will fail when requesting zero defined irqs. Sorry, not noting this before. Jarkko commit c29cfcead32c8dcb9738a085d498aebe6ab160af Author: Jarkko Nikula <[EMAIL PROTECTED]> Date: Tue Sep 16 15:56:53 2008 +0300 ARM: OMAP: Add RX/TX interrupts for 2430 and 34xx McBSP ports 3-5 Without RX and TX interrupt definitions, the omap_mcbsp_request will fail on OMAP2430 and OMAP34xx for ports 3-5 since default io_type is OMAP_MCBSP_IRQ_IO. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] input: tsc2005: move to gpiolib
On Tuesday 14 October 2008, Felipe Balbi wrote: > - omap_set_gpio_direction(dav_gpio, 1); > + gpio_direction_input(dav_gpio); > ts->irq = OMAP_GPIO_IRQ(dav_gpio); That should be ts->irq = gpio_to_irq(dav_gpio) ... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
On Tue, Oct 14, 2008 at 02:44:51PM -0700, David Brownell wrote: > On Tuesday 14 October 2008, Felipe Balbi wrote: > > I'd say that if it goes to the "wrong" place and doesn't bother anyone, > > will get forgotten. Just like the whole bunch of other drivers sitting > > in linux-omap... > > I thought the point was to have them sit in mainline. ;) Exactly :-) > Some of these drivers are first-of-a-kind, so these questions wouldn't > necessarily have come up before. That's one of the obstacles to > mainline merge that isn't always acknowledged. That's also true, but then again most of those drivers got forgotten and never made their way to mainline. If you look at mainline archives, you'll see that most of omap drivers never "tried" to go upstream. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
On Tuesday 14 October 2008, Felipe Balbi wrote: > I'd say that if it goes to the "wrong" place and doesn't bother anyone, > will get forgotten. Just like the whole bunch of other drivers sitting > in linux-omap... I thought the point was to have them sit in mainline. ;) > Funny that most of such drivers are for nokia tablets :-p Some of these drivers are first-of-a-kind, so these questions wouldn't necessarily have come up before. That's one of the obstacles to mainline merge that isn't always acknowledged. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] leds: lp5521: move to drivers/leds
From: Felipe Balbi <[EMAIL PROTECTED]>
This driver should be sitting together with the other
led drivers.
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig |7 ---
drivers/i2c/chips/Makefile |1 -
drivers/leds/Kconfig | 10 ++
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} |0
5 files changed, 11 insertions(+), 8 deletions(-)
rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (100%)
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index d803c41..0aed293 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -219,13 +219,6 @@ config SENSORS_TSL2563
This driver can also be built as a module. If so, the module
will be called tsl2563.
-config LP5521
- tristate "LP5521 LED driver chip"
- depends on I2C
- help
- If you say yes here you get support for the National Semiconductor
- LP5521 LED driver.
-
config MENELAUS
bool "TWL92330/Menelaus PM chip"
depends on I2C=y && ARCH_OMAP24XX
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ba41a57..5e17df3 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -30,7 +30,6 @@ obj-$(CONFIG_TWL4030_POWEROFF)+= twl4030-poweroff.o
obj-$(CONFIG_TWL4030_PWRBUTTON)+= twl4030-pwrbutton.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_RTC_X1205_I2C)+= x1205.o
-obj-$(CONFIG_LP5521) += lp5521.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 6a2f441..943e3d9 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -146,6 +146,16 @@ config LEDS_CM_X270
help
This option enables support for the CM-X270 LEDs.
+config LEDS_LP5521
+ tristate "LED Support for the LP5521 LEDs"
+ depends on LEDS_CLASS && I2C
+ help
+ If you say 'Y' here you get support for the National Semiconductor
+ LP5521 LED driver used in n8x0 boards.
+
+ This driver can be built as a module by choosing 'M'. The module
+ will be called leds-lp5521.
+
config LEDS_CLEVO_MAIL
tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index fd6316e..ce5c8cd 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/leds/leds-lp5521.c
similarity index 100%
rename from drivers/i2c/chips/lp5521.c
rename to drivers/leds/leds-lp5521.c
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] i2c: lp5521: move to LED framework
From: Felipe Balbi <[EMAIL PROTECTED]>
Register three separate leds for lp5521 and allow
them to be controlled separately while keeping
backwards compatibility with userspace programs
based on old implementation.
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/lp5521.c | 146 +++-
1 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index 9e94ff8..a5c3425 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -4,6 +4,7 @@
* Copyright (C) 2007 Nokia Corporation
*
* Written by Mathias Nyman <[EMAIL PROTECTED]>
+ * Updated by Felipe Balbi <[EMAIL PROTECTED]>
*
* 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
@@ -23,7 +24,9 @@
#include
#include
#include
+#include
#include
+#include
#define LP5521_DRIVER_NAME "lp5521"
@@ -75,7 +78,17 @@ struct lp5521_chip {
/* device lock */
struct mutexlock;
struct i2c_client *client;
+
+ struct work_struct red_work;
+ struct work_struct green_work;
+ struct work_struct blue_work;
+
+ struct led_classdev ledr;
+ struct led_classdev ledg;
+ struct led_classdev ledb;
+
enum lp5521_modemode;
+
int red;
int green;
int blue;
@@ -489,6 +502,87 @@ static int lp5521_set_mode(struct lp5521_chip *chip, enum
lp5521_mode mode)
return ret;
}
+static void lp5521_red_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
red_work);
+ int ret;
+
+ ret = lp5521_configure(chip->client);
+ if (ret) {
+ dev_dbg(&chip->client->dev, "could not configure lp5521, %d\n",
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip->client, LP5521_REG_R_PWM, chip->red);
+ if (ret)
+ dev_dbg(&chip->client->dev, "could not set brightness, %d\n",
+ ret);
+}
+
+static void lp5521_red_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledr);
+
+ chip->red = value;
+ schedule_work(&chip->red_work);
+}
+
+static void lp5521_green_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
green_work);
+ int ret;
+
+ ret = lp5521_configure(chip->client);
+ if (ret) {
+ dev_dbg(&chip->client->dev, "could not configure lp5521, %d\n",
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip->client, LP5521_REG_G_PWM, chip->green);
+ if (ret)
+ dev_dbg(&chip->client->dev, "could not set brightness, %d\n",
+ ret);
+}
+
+static void lp5521_green_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledg);
+
+ chip->green = value;
+ schedule_work(&chip->green_work);
+}
+
+static void lp5521_blue_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
blue_work);
+ int ret;
+
+ ret = lp5521_configure(chip->client);
+ if (ret) {
+ dev_dbg(&chip->client->dev, "could not configure lp5521, %d\n",
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip->client, LP5521_REG_B_PWM, chip->blue);
+ if (ret)
+ dev_dbg(&chip->client->dev, "could not set brightness, %d\n",
+ ret);
+}
+
+static void lp5521_blue_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledb);
+
+ chip->blue = value;
+ schedule_work(&chip->blue_work);
+}
+
/*--*/
/* Probe, Attach, Remove */
/*--*/
@@ -509,6 +603,10 @@ static int __init lp5521_probe(struct i2c_client *client,
mutex_init(&chip->lock);
+ INIT_WORK(&chip->red_work, lp5521_red_work);
+ INIT_WORK(&chip->green_work, lp5521_green_work);
+ INIT_WORK(&chip->blue_work, lp5521_blue_work);
+
ret = lp5521_configure(client);
if (ret < 0) {
dev_err(&client->dev, "lp5521 error configuring chip \n");
@@ -521,14 +619,52 @@ static int __init lp5521_probe(struct i2c_client *client,
chip->green
[PATCH 5/7] i2c: lp5521: simplify mode setting
From: Felipe Balbi <[EMAIL PROTECTED]>
Avoid using string magic and use integer for comparisson
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/lp5521.c | 52 ---
1 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index e040c4d..9e94ff8 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -46,10 +46,6 @@
#define LP5521_REG_G_PROG_MEM 0x30
#define LP5521_REG_B_PROG_MEM 0x50
-#define LP5521_MODE_LOAD "load"
-#define LP5521_MODE_RUN"run"
-#define LP5521_MODE_DIRECT_CONTROL "direct"
-
#define LP5521_CURRENT_1m5 0x0f
#define LP5521_CURRENT_3m1 0x1f
#define LP5521_CURRENT_4m7 0x2f
@@ -69,17 +65,23 @@
#define LP5521_PROGRAM_LENGTH 32 /* in bytes */
+enum lp5521_mode {
+ LP5521_MODE_LOAD,
+ LP5521_MODE_RUN,
+ LP5521_MODE_DIRECT_CONTROL,
+};
+
struct lp5521_chip {
/* device lock */
struct mutexlock;
struct i2c_client *client;
- char*mode;
+ enum lp5521_modemode;
int red;
int green;
int blue;
};
-static int lp5521_set_mode(struct lp5521_chip *chip, char *mode);
+static int lp5521_set_mode(struct lp5521_chip *chip, enum lp5521_mode mode);
static inline int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
{
@@ -313,8 +315,25 @@ static ssize_t show_mode(struct device *dev,
char *buf)
{
struct lp5521_chip *chip = dev_get_drvdata(dev);
+ char *mode;
+
+ mutex_lock(&chip->lock);
+ switch (chip->mode) {
+ case LP5521_MODE_RUN:
+ mode = "run";
+ break;
+ case LP5521_MODE_LOAD:
+ mode = "load";
+ break;
+ case LP5521_MODE_DIRECT_CONTROL:
+ mode = "direct";
+ break;
+ default:
+ mode = "undefined";
+ }
+ mutex_unlock(&chip->lock);
- return sprintf(buf, "%s\n", chip->mode);
+ return sprintf(buf, "%s\n", mode);
}
static ssize_t store_mode(struct device *dev,
@@ -442,23 +461,28 @@ static void lp5521_unregister_sysfs(struct i2c_client
*client)
/* Set chip operating mode */
/*--*/
-static int lp5521_set_mode(struct lp5521_chip *chip, char *mode)
+static int lp5521_set_mode(struct lp5521_chip *chip, enum lp5521_mode mode)
{
struct i2c_client *client = chip->client ;
int ret = 0;
/* if in that mode already do nothing, except for run */
- if (!strcmp(mode, chip->mode) && strcmp(mode, LP5521_MODE_RUN))
+ if (chip->mode == mode && mode != LP5521_MODE_RUN)
return 0;
- if (!strcmp(mode, LP5521_MODE_RUN))
+ switch (mode) {
+ case LP5521_MODE_RUN:
ret = lp5521_run_program(chip);
-
- if (!strcmp(mode, LP5521_MODE_LOAD))
+ break;
+ case LP5521_MODE_LOAD:
ret |= lp5521_write(client, LP5521_REG_OP_MODE, 0x15);
-
- if (!strcmp(mode, LP5521_MODE_DIRECT_CONTROL))
+ break;
+ case LP5521_MODE_DIRECT_CONTROL:
ret |= lp5521_write(client, LP5521_REG_OP_MODE, 0x3F);
+ break;
+ default:
+ dev_dbg(&client->dev, "unsupported mode %d\n", mode);
+ }
chip->mode = mode;
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] i2c: lp5521: cosmetic fixes
From: Felipe Balbi <[EMAIL PROTECTED]>
General cleanup to the code. Preparing to send it to
mainline.
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/lp5521.c | 159
1 files changed, 73 insertions(+), 86 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index 7fb8091..e040c4d 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -1,5 +1,5 @@
/*
- * drivers/i2c/chips/lp5521.c
+ * lp5521.c - LP5521 LED Driver
*
* Copyright (C) 2007 Nokia Corporation
*
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#define LP5521_DRIVER_NAME "lp5521"
@@ -71,6 +70,7 @@
#define LP5521_PROGRAM_LENGTH 32 /* in bytes */
struct lp5521_chip {
+ /* device lock */
struct mutexlock;
struct i2c_client *client;
char*mode;
@@ -81,20 +81,14 @@ struct lp5521_chip {
static int lp5521_set_mode(struct lp5521_chip *chip, char *mode);
-static int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
+static inline int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
{
return i2c_smbus_write_byte_data(client, reg, value);
}
-static int lp5521_read(struct i2c_client *client, u8 reg, u8 *buf)
+static inline int lp5521_read(struct i2c_client *client, u8 reg)
{
- s32 ret = i2c_smbus_read_byte_data(client, reg);
-
- if (ret < 0)
- return -EIO;
-
- *buf = ret;
- return 0;
+ return i2c_smbus_read_byte_data(client, reg);
}
static int lp5521_configure(struct i2c_client *client)
@@ -136,19 +130,19 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
if (chip->red)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_R_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_R_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip->green)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_G_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_G_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip->blue)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_B_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_B_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
return ret;
}
@@ -156,31 +150,33 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
static int lp5521_run_program(struct lp5521_chip *chip)
{
struct i2c_client *client = chip->client;
- int ret;
+ int reg;
u8 mask = 0xc0;
u8 exec_state = 0;
- u8 enable_reg;
- ret = lp5521_read(client, LP5521_REG_ENABLE, &enable_reg);
- if (ret)
- goto fail;
+ reg = lp5521_read(client, LP5521_REG_ENABLE);
+ if (reg < 0)
+ return reg;
- enable_reg &= mask;
+ reg &= mask;
/* set all active channels exec state to countinous run*/
- exec_state |= (chip->red << 5);
+ exec_state |= (chip->red << 5);
exec_state |= (chip->green << 3);
- exec_state |= (chip->blue << 1);
+ exec_state |= (chip->blue << 1);
- enable_reg |= exec_state;
+ reg |= exec_state;
- ret |= lp5521_write(client, LP5521_REG_ENABLE, enable_reg);
+ if (lp5521_write(client, LP5521_REG_ENABLE, reg))
+ dev_dbg(&client->dev, "failed writing to register %02x\n",
+ LP5521_REG_ENABLE);
/* set op-mode to run for active channels, disabled for others */
- ret |= lp5521_write(client, LP5521_REG_OP_MODE, exec_state);
+ if (lp5521_write(client, LP5521_REG_OP_MODE, exec_state))
+ dev_dbg(&client->dev, "failed writing to register %02x\n",
+ LP5521_REG_OP_MODE);
-fail:
- return ret;
+ return 0;
}
/*--*/
@@ -188,8 +184,8 @@ fail:
/*--*/
static ssize_t show_active_channels(struct device *dev,
-
[PATCH 3/7] i2c: lp5521: remove dead code
From: Felipe Balbi <[EMAIL PROTECTED]> That LED_CONNECTED_WRONG was never defined so removing. If someone needs those hooks, add back via proper platform_data instead of nasty ifdefery. Cc: Richard Purdie <[EMAIL PROTECTED]> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> --- drivers/i2c/chips/lp5521.c | 22 -- 1 files changed, 0 insertions(+), 22 deletions(-) diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c index c0862d9..7fb8091 100644 --- a/drivers/i2c/chips/lp5521.c +++ b/drivers/i2c/chips/lp5521.c @@ -28,13 +28,8 @@ #define LP5521_DRIVER_NAME "lp5521" -#ifdef LED_CONNECTED_WRONG -#define LP5521_REG_R_PWM 0x04 -#define LP5521_REG_B_PWM 0x02 -#else #define LP5521_REG_R_PWM 0x02 #define LP5521_REG_B_PWM 0x04 -#endif #define LP5521_REG_ENABLE 0x00 #define LP5521_REG_OP_MODE 0x01 #define LP5521_REG_G_PWM 0x03 @@ -200,22 +195,12 @@ static ssize_t show_active_channels(struct device *dev, char channels[4]; int pos = 0; -#ifdef LED_CONNECTED_WRONG - if (chip->blue) - pos += sprintf(channels + pos, "r"); - if (chip->green) - pos += sprintf(channels + pos, "g"); - if (chip->red) - pos += sprintf(channels + pos, "b"); - -#else if (chip->red) pos += sprintf(channels + pos, "r"); if (chip->green) pos += sprintf(channels + pos, "g"); if (chip->blue) pos += sprintf(channels + pos, "b"); -#endif channels[pos] = '\0'; @@ -232,17 +217,10 @@ static ssize_t store_active_channels(struct device *dev, chip->green = 0; chip->blue = 0; -#ifdef LED_CONNECTED_WRONG - if (strchr(buf, 'r') != NULL) - chip->blue = 1; - if (strchr(buf, 'b') != NULL) - chip->red = 1; -#else if (strchr(buf, 'r') != NULL) chip->red = 1; if (strchr(buf, 'b') != NULL) chip->blue = 1; -#endif if (strchr(buf, 'g') != NULL) chip->green = 1; -- 1.6.0.2.307.gc427 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] input: tsc2005: move to gpiolib
From: Felipe Balbi <[EMAIL PROTECTED]>
Get rid of omap-specific gpio calls and switch over
to gpiolib.
Cc: David Brownell <[EMAIL PROTECTED]>
Cc: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/input/touchscreen/tsc2005.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 7fb107e..c9f8f5c 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -534,16 +534,14 @@ static int __devinit tsc2005_ts_init(struct tsc2005 *ts,
ts->dav_gpio = dav_gpio;
dev_dbg(&ts->spi->dev, "TSC2005: DAV GPIO = %d\n", dav_gpio);
-#ifdef CONFIG_ARCH_OMAP
- r = omap_request_gpio(dav_gpio);
+ r = gpio_request(dav_gpio, "dav_gpio");
if (r < 0) {
dev_err(&ts->spi->dev, "unable to get DAV GPIO");
goto err1;
}
- omap_set_gpio_direction(dav_gpio, 1);
+ gpio_direction_input(dav_gpio);
ts->irq = OMAP_GPIO_IRQ(dav_gpio);
dev_dbg(&ts->spi->dev, "TSC2005: DAV IRQ = %d\n", ts->irq);
-#endif
init_timer(&ts->penup_timer);
setup_timer(&ts->penup_timer, tsc2005_ts_penup_timer_handler,
(unsigned long)ts);
@@ -612,9 +610,7 @@ err3:
tsc2005_stop_scan(ts);
input_free_device(idev);
err2:
-#ifdef CONFIG_ARCH_OMAP
- omap_free_gpio(dav_gpio);
-#endif
+ gpio_free(dav_gpio);
err1:
return r;
}
@@ -671,10 +667,7 @@ static int __devexit tsc2005_remove(struct spi_device *spi)
free_irq(ts->irq, ts);
input_unregister_device(ts->idev);
-
-#ifdef CONFIG_ARCH_OMAP
- omap_free_gpio(ts->dav_gpio);
-#endif
+ gpio_free(ts->dav_gpio);
kfree(ts);
return 0;
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] input: lm8323: get rid of global pdata pointer
From: Felipe Balbi <[EMAIL PROTECTED]>
pdata is only used during probe to initialize a few fields
from lm8323 device structure. Moving pdata pointer to probe
won't harm anybody.
Cc: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/input/keyboard/lm8323.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 72bb587..b6f464c 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -184,9 +184,6 @@ static struct lm8323_chip *pwm_to_lm8323(struct lm8323_pwm
*pwm)
}
}
-static struct lm8323_platform_data *lm8323_pdata;
-
-
#define LM8323_MAX_DATA 8
/*
@@ -673,6 +670,7 @@ static DEVICE_ATTR(disable_kp, 0644, lm8323_show_disable,
lm8323_set_disable);
static int lm8323_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct lm8323_platform_data *lm8323_pdata;
struct input_dev *idev;
struct lm8323_chip *lm;
int i, err = 0;
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] updates to few nokia drivers
From: Felipe Balbi <[EMAIL PROTECTED]>
Preparing few drivers for integration upstream.
At least lp5521 should be in good shape for going
upstream. lm8323 and tsc2005 might need some more
work.
Felipe Balbi (7):
input: lm8323: get rid of global pdata pointer
input: tsc2005: move to gpiolib
i2c: lp5521: remove dead code
i2c: lp5521: cosmetic fixes
i2c: lp5521: simplify mode setting
i2c: lp5521: move to LED framework
leds: lp5521: move to drivers/leds
drivers/i2c/chips/Kconfig |7 -
drivers/i2c/chips/Makefile |1 -
drivers/input/keyboard/lm8323.c|4 +-
drivers/input/touchscreen/tsc2005.c| 15 +-
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} | 379 +---
7 files changed, 271 insertions(+), 146 deletions(-)
rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (62%)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
On Tue, Oct 14, 2008 at 02:24:10PM -0700, Tony Lindgren wrote: > * Igor Stoppa <[EMAIL PROTECTED]> [081014 14:12]: > > On Tue, 2008-10-14 at 13:59 -0700, ext Tony Lindgren wrote: > > > > > And that we can use same naming in the driver no matter which omap :) > > > > Wasn't that one of the main features of the clock FW, when it was > > designed? > > Yes. But we adding separate ick and fck during omap2420 confused that. Also, it's useful to keep the name shown in TRM to ease the task of searching TRM for information about that particular clock. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
* Igor Stoppa <[EMAIL PROTECTED]> [081014 14:12]: > On Tue, 2008-10-14 at 13:59 -0700, ext Tony Lindgren wrote: > > > And that we can use same naming in the driver no matter which omap :) > > Wasn't that one of the main features of the clock FW, when it was > designed? Yes. But we adding separate ick and fck during omap2420 confused that. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
On Tue, Oct 14, 2008 at 09:00:55AM -0700, David Brownell wrote: > On Tuesday 14 October 2008, Felipe Balbi wrote: > > > > > Nack. Light sensors have nothing to do with hardware monitoring. > > > > > > The only light sensor driver in the kernel tree at the moment > > > is drivers/i2c/chips/tsl2550.c. But I'm not very happy with this > > > either, as my ultimate goal is to delete the drivers/i2c/chips > > > directory completely. So we should find a new home for light sensors. > > > > and that's why I'm moving nokia drivers out of drivers/i2c/chips > > directory. > > > > > Maybe they should go into the new "industrial I/O" subsystem. Or if > > > not, their own drivers/sensors/light directory. > > > > Well, could be. We might need someone else, like Andrew, to answer that > > question. > > My two cents: leave them where they are until a "good" answer exists. > Or if drivers/i2c/chips is sufficiently annoying ... drivers/misc may > be a good interim site. I'd say that if it goes to the "wrong" place and doesn't bother anyone, will get forgotten. Just like the whole bunch of other drivers sitting in linux-omap. They don't bother anyone (probably they bother Tony when API changes upstream and a few defconfigs don't build anymore) so they got forgotten and still sitting in linux-omap. Funny that most of such drivers are for nokia tablets :-p -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
On Tue, 2008-10-14 at 13:59 -0700, ext Tony Lindgren wrote: > And that we can use same naming in the driver no matter which omap :) Wasn't that one of the main features of the clock FW, when it was designed? -- Cheers, Igor --- Igor Stoppa Maemo Software - Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
* Felipe Balbi <[EMAIL PROTECTED]> [081014 12:31]: > On Tue, Oct 14, 2008 at 10:47:44AM -0700, David Brownell wrote: > > On Tuesday 14 October 2008, Felipe Balbi wrote: > > > I didn't quite get you here. The idea of mmc_fck is so that > > > > > > clk_get(dev, "mmc_fck"); > > > > > > works fine and returns the correct clock. If we have several fck and ick > > > function names, how will we clk_get() the right one ?? > > > > If "dev" is an MMC device, there's no way to confuse > > its "fck" and "ick" with those for, say, I2C. Right? > > That's the whole point of associating logical clock > > names with the device. > > > > And as Paul noted, if a device has several such clocks, > > then it needs several such names. > > hmm... that's true. Forgot about matching dev as well :-p > hehehe. Makes sense to me, let's use fclk and iclk then :-) > > The main idea then would be that clk(dev, "iclk") translates to english > into "get me the interface clock of mmc device" (when dev is an mmc > device, of course). And that we can use same naming in the driver no matter which omap :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull request for minimal omap3 support one more time
* Tony Lindgren <[EMAIL PROTECTED]> [081014 13:37]:
> * Russell King - ARM Linux <[EMAIL PROTECTED]> [081014 12:39]:
> > On Tue, Oct 14, 2008 at 10:19:08AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <[EMAIL PROTECTED]> [081013 09:15]:
> > > > There's something wrong with one of the sets I've pulled from you:
> > > >
> > > > arch/arm/mach-omap2/mcbsp.c:253: error: ???INT_24XX_MCBSP3_IRQ_RX???
> > > > undeclared here (not in a function)
> > > > arch/arm/mach-omap2/mcbsp.c:254: error: ???INT_24XX_MCBSP3_IRQ_TX???
> > > > undeclared here (not in a function)
> > > > arch/arm/mach-omap2/mcbsp.c:262: error: ???INT_24XX_MCBSP4_IRQ_RX???
> > > > undeclared here (not in a function)
> > > > arch/arm/mach-omap2/mcbsp.c:263: error: ???INT_24XX_MCBSP4_IRQ_TX???
> > > > undeclared here (not in a function)
> > > > arch/arm/mach-omap2/mcbsp.c:271: error: ???INT_24XX_MCBSP5_IRQ_RX???
> > > > undeclared here (not in a function)
> > > > arch/arm/mach-omap2/mcbsp.c:272: error: ???INT_24XX_MCBSP5_IRQ_TX???
> > > > undeclared here (not in a function)
> > > >
> > > > Please take a look and resolve ASAP. Thanks.
> > >
> > > Sorry for the delay, I was sitting in an airplane again.
> > >
> > > Here's the fix, looks like the missing McBSP irqs should have been
> > > merged into the recent McBSP patches.
> > >
> > > This patch is also in your patch system as 5301/1.
> >
> > Thanks, that solved that problem, but there's one more to come:
> >
> > arch/arm/plat-omap/devices.c: In function 'omap_mcbsp_register_board_cfg':
> > arch/arm/plat-omap/devices.c:163: error: 'OMAP_MAX_MCBSP_COUNT' undeclared
> > (first use in this function)
> > arch/arm/plat-omap/devices.c:163: error: (Each undeclared identifier is
> > reported only once
> > arch/arm/plat-omap/devices.c:163: error: for each function it appears in.)
> >
> > The good news is that that seems to be the last error building for LDP.
>
> Grrr, just few mins and I'll send a patch. Will also build test this
> time :)
Here's the patch to fix this. Also available in your patch system as 5305/1.
Regards,
Tony
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Tue, 14 Oct 2008 13:43:48 -0700
Subject: [PATCH] ARM: OMAP: Fix compile of McBSP by removing unnecessary check
Recent McBSP patches changed to allocating devices dynamically
and the check for OMAP_MAX_MCBSP_COUNT became unnecessary.
The check for OMAP_MAX_MCBSP_COUNT should have been removed with
the earlier McBSP patches in devices.c but was accidentally left
out.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -159,13 +159,6 @@ void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data *config,
{
int i;
- if (size > OMAP_MAX_MCBSP_COUNT) {
- printk(KERN_WARNING "Registered too many McBSPs platform_data."
- " Using maximum (%d) available.\n",
- OMAP_MAX_MCBSP_COUNT);
- size = OMAP_MAX_MCBSP_COUNT;
- }
-
omap_mcbsp_devices = kzalloc(size * sizeof(struct platform_device *),
GFP_KERNEL);
if (!omap_mcbsp_devices) {
Re: [PATCH] ARM: OMAP: Revert omap3 WDT changes to avoid merge conflict (Re: linux-next: manual merge of the arm tree)
On Tue, Oct 14, 2008 at 01:30:24PM -0700, Tony Lindgren wrote: > And here's the patch for Russell to avoid the merge conflict. > Also in Russell's patch tracking system as patch 5302/1. This evening, only now having the time to investigate what's going on there (as a result of added your other patch to fix the build error I reported on Saturday) it turns out to be much more trivial a conflict than I was suspecting from sfr's description. However, the results of the final merge with 'master' on my devel branch never go to Linus, so your patch may still be required. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull request for minimal omap3 support one more time
* Russell King - ARM Linux <[EMAIL PROTECTED]> [081014 12:39]: > On Tue, Oct 14, 2008 at 10:19:08AM -0700, Tony Lindgren wrote: > > * Russell King - ARM Linux <[EMAIL PROTECTED]> [081013 09:15]: > > > There's something wrong with one of the sets I've pulled from you: > > > > > > arch/arm/mach-omap2/mcbsp.c:253: error: ???INT_24XX_MCBSP3_IRQ_RX??? > > > undeclared here (not in a function) > > > arch/arm/mach-omap2/mcbsp.c:254: error: ???INT_24XX_MCBSP3_IRQ_TX??? > > > undeclared here (not in a function) > > > arch/arm/mach-omap2/mcbsp.c:262: error: ???INT_24XX_MCBSP4_IRQ_RX??? > > > undeclared here (not in a function) > > > arch/arm/mach-omap2/mcbsp.c:263: error: ???INT_24XX_MCBSP4_IRQ_TX??? > > > undeclared here (not in a function) > > > arch/arm/mach-omap2/mcbsp.c:271: error: ???INT_24XX_MCBSP5_IRQ_RX??? > > > undeclared here (not in a function) > > > arch/arm/mach-omap2/mcbsp.c:272: error: ???INT_24XX_MCBSP5_IRQ_TX??? > > > undeclared here (not in a function) > > > > > > Please take a look and resolve ASAP. Thanks. > > > > Sorry for the delay, I was sitting in an airplane again. > > > > Here's the fix, looks like the missing McBSP irqs should have been > > merged into the recent McBSP patches. > > > > This patch is also in your patch system as 5301/1. > > Thanks, that solved that problem, but there's one more to come: > > arch/arm/plat-omap/devices.c: In function 'omap_mcbsp_register_board_cfg': > arch/arm/plat-omap/devices.c:163: error: 'OMAP_MAX_MCBSP_COUNT' undeclared > (first use in this function) > arch/arm/plat-omap/devices.c:163: error: (Each undeclared identifier is > reported only once > arch/arm/plat-omap/devices.c:163: error: for each function it appears in.) > > The good news is that that seems to be the last error building for LDP. Grrr, just few mins and I'll send a patch. Will also build test this time :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: Revert omap3 WDT changes to avoid merge conflict (Re: linux-next: manual merge of the arm tree)
* Tony Lindgren <[EMAIL PROTECTED]> [081014 13:09]:
> * David Brownell <[EMAIL PROTECTED]> [081014 11:53]:
> > On Tuesday 14 October 2008, Russell King wrote:
> > > Since the OMAP updates I merged from Tony are already broken due to
> > > missing definitions, and I'm not getting any response from Tony on
> > > fixing those,
>
> I just sent you a fix for that few hours ago.
>
> > Probably has to do with his travel plans, which he mentioned
> > last week (Thursday?). I think he's back online in the next
> > day or two.
> >
> >
> > > I will be dropping the problematical updates so we can
> > > at least keep mainline OMAP in a buildable state. That seems to mean
> > > dropping the new OMAP3 support.
>
> Yes, I'm back online. And please don't drop these patches, sounds
> like this is a trivial merge issue.
And here's the patch for Russell to avoid the merge conflict.
Also in Russell's patch tracking system as patch 5302/1.
>
> Regards,
>
> Tony
From: Tony Lindgren <[EMAIL PROTECTED]>
Date: Tue, 14 Oct 2008 13:25:20 -0700
Subject: [PATCH] ARM: OMAP: Revert omap3 WDT changes to avoid merge conflict
With the upcoming WDT patches OMAP_WDT_BASE is no longer needed
in devices.c. Revert some earlier omap3 changes to avoid merge
conflicts with the WDT patches.
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -399,17 +399,8 @@ static inline void omap_init_uwire(void) {}
#if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-#if defined(CONFIG_ARCH_OMAP34XX)
-#define OMAP_WDT_BASE 0x48314000
-#elif defined(CONFIG_ARCH_OMAP24XX)
-
-#ifdef CONFIG_ARCH_OMAP2430
-/* WDT2 */
-#define OMAP_WDT_BASE 0x49016000
-#else
+#ifdef CONFIG_ARCH_OMAP24XX
#define OMAP_WDT_BASE 0x48022000
-#endif
-
#else
#define OMAP_WDT_BASE 0xfffeb000
#endif
Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
Hi Paul, I understood both points you explained below, while I still think that standardizing clock names may be a little bit rigid. Thank you for your review and comments. Hiroshi DOYU From: "ext Paul Walmsley" <[EMAIL PROTECTED]> Subject: Re: [PATCH 1/3] [RFC] clk: introduce clk_associate Date: Tue, 14 Oct 2008 10:33:42 -0600 (MDT) > > Hi, > > between omap_clk_associate() and vclk, my preference is for the > omap_clk_associate() approach. > > The core problem is that the vclk patches create clocks with multiple > parents in a way that is hidden from the clock framework. This causes > both semantic and practical problems. > > Semantically, the patches cause the meaning of set_rate() and set_parent() > to be confused, and any driver that wants to call set_parent() or > set_rate() on those clocks will need to have their own custom functions > for those operations. I'd like to keep the amount of that custom code > minimized. > > In practical terms, the vclk code will cause spinlock recursion bugs like > the ones that currently exist with the McBSP driver: > >http://marc.info/?l=linux-omap&m=122310205615940&w=2 > > since vclks will call clk_enable()/disable()/set_rate()/etc. inside the > clockfw_lock spinlock. Using the vclk patches also means that the number > of custom clocks will explode, as each driver is likely to define at > least one custom clock. > > [ eventually, we'll need to deal with the multiple parent issue, if for no > other reason than to fix usecounting for clocks like dss_ick. But it will > need to be handled by the clock framework code itself. And this problem > is pretty low on the priority list... ] > > So between the two, I'd like to see omap_clk_associate() integrated. I > have some comments to post on Felipe's code; once those are > addressed, hopefully we can merge it. > > > - Paul > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the arm tree
* David Brownell <[EMAIL PROTECTED]> [081014 11:53]: > On Tuesday 14 October 2008, Russell King wrote: > > Since the OMAP updates I merged from Tony are already broken due to > > missing definitions, and I'm not getting any response from Tony on > > fixing those, I just sent you a fix for that few hours ago. > Probably has to do with his travel plans, which he mentioned > last week (Thursday?). I think he's back online in the next > day or two. > > > > I will be dropping the problematical updates so we can > > at least keep mainline OMAP in a buildable state. That seems to mean > > dropping the new OMAP3 support. Yes, I'm back online. And please don't drop these patches, sounds like this is a trivial merge issue. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] Hook into powerdomain code
On Tue, 14 Oct 2008, Peter 'p2' De Schrijver wrote:
> @@ -179,9 +183,12 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
> {
> struct powerdomain **p = NULL;
>
> - if (pwrdm_list)
> - for (p = pwrdm_list; *p; p++)
> + if (pwrdm_list) {
> + for (p = pwrdm_list; *p; p++) {
> pwrdm_register(*p);
> + _pwrdm_setup(*p);
perhaps I am going blind - could you point me at where _pwrdm_setup() is
defined?
> + }
> + }
> }
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Add closures to clkdm_for_each and pwrdm_for_each.
Hello Peter,
one very minor comment:
On Tue, 14 Oct 2008, Peter 'p2' De Schrijver wrote:
> diff --git a/arch/arm/plat-omap/include/mach/powerdomain.h
> b/arch/arm/plat-omap/include/mach/powerdomain.h
> index 52663fc..6271d85 100644
> --- a/arch/arm/plat-omap/include/mach/powerdomain.h
> +++ b/arch/arm/plat-omap/include/mach/powerdomain.h
> @@ -119,6 +119,11 @@ struct powerdomain {
>
> int state;
> unsigned state_counter[4];
> +
> +#ifdef CONFIG_PM_DEBUG
> + s64 timer;
> + s64 state_timer[4];
> +#endif
> };
this probably goes best in patch 2/3?
Other than that, looks good to me.
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Add pm-debug counters
Hi Peter
a few quick comments...
On Tue, 14 Oct 2008, Peter 'p2' De Schrijver wrote:
> This patch provides the debugfs entries and a function which will be called
> by the PM code to register the time spent per domain per state.
>
> Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
> ---
> arch/arm/mach-omap2/pm-debug.c| 175
> +
> arch/arm/mach-omap2/pm.h |2 +
> 2 files changed, 177 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 0b5c044..4ba6cec 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -29,6 +29,8 @@
>
> #include
> #include
> +#include
> +#include
>
> #include "prm.h"
> #include "cm.h"
> @@ -288,4 +290,177 @@ void omap2_pm_dump(int mode, int resume, unsigned int
> us)
> printk("%-20s: 0x%08x\n", regs[i].name, regs[i].val);
> }
>
> +#ifdef CONFIG_DEBUG_FS
> +#include
> +#include
> +
> +struct dentry *pm_dbg_dir;
> +
> +static int pm_dbg_init_done;
> +
> +enum {
> + DEBUG_FILE_COUNTERS = 0,
> + DEBUG_FILE_TIMERS,
> +};
> +
> +static const char pwrdm_state_names[][4] = {
> + "OFF",
> + "RET",
> + "INA",
> + "ON"
> +};
> +
> +void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
> +{
> + s64 t;
> + struct timespec now;
> +
> + if (!pm_dbg_init_done)
> + return ;
> +
> + /* Update timer for previous state */
> + getnstimeofday(&now);
> + t = timespec_to_ns(&now);
> +
> + pwrdm->state_timer[prev] += t - pwrdm->timer;
> +
> + pwrdm->timer = t;
> +}
> +
> +static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
> +{
> + struct seq_file *s = (struct seq_file *)user;
> +
> + if (strcmp(clkdm->name, "emu_clkdm") == 0 ||
> + strcmp(clkdm->name, "wkup_clkdm") == 0)
> + return 0;
Is this code intended to skip clockdomains that have no hardware counters?
Maybe we should add a flag in the struct clockdomain for this.
> +
> + seq_printf(s, "%s->%s (%d)", clkdm->name,
> + clkdm->pwrdm.ptr->name,
> + atomic_read(&clkdm->usecount));
> + seq_printf(s, "\n");
> +
> + return 0;
> +}
> +
> +static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void *user)
> +{
> + struct seq_file *s = (struct seq_file *)user;
> + int i;
> +
> + if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
> + strcmp(pwrdm->name, "wkup_pwrdm") == 0)
> + return 0;
likewise
> +
> + if (pwrdm->state != pwrdm_read_pwrst(pwrdm))
> + printk(KERN_ERR "pwrdm state mismatch(%s) %d != %d\n",
> + pwrdm->name, pwrdm->state, pwrdm_read_pwrst(pwrdm));
> +
> + seq_printf(s, "%s (%s)", pwrdm->name,
> + pwrdm_state_names[pwrdm->state]);
> + for (i = 0; i < 4; i++)
how about
for (i = 0; i < ARRAY_SIZE(pwrdm_state_names); i++)
?
> + seq_printf(s, ",%s:%d", pwrdm_state_names[i],
> + pwrdm->state_counter[i]);
> +
> + seq_printf(s, "\n");
> +
> + return 0;
> +}
> +
> +static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user)
> +{
> + struct seq_file *s = (struct seq_file *)user;
> + int i;
> +
> + if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
> + strcmp(pwrdm->name, "wkup_pwrdm") == 0)
> + return 0;
likewise with the clockdomain flag comment
> +
> + pwrdm_state_switch(pwrdm);
> +
> + seq_printf(s, "%s (%s)", pwrdm->name,
> + pwrdm_state_names[pwrdm->state]);
> +
> + for (i = 0; i < 4; i++)
ARRAY_SIZE()
> + seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
> + pwrdm->state_timer[i]);
> +
> + seq_printf(s, "\n");
> +
> + return 0;
> +}
> +
> +static void pm_dbg_show_counters(struct seq_file *s, void *unused)
> +{
> + pwrdm_for_each(pwrdm_dbg_show_counter, s);
> + clkdm_for_each(clkdm_dbg_show_counter, s);
> +}
> +
> +static void pm_dbg_show_timers(struct seq_file *s, void *unused)
> +{
> + pwrdm_for_each(pwrdm_dbg_show_timer, s);
> +}
> +
> +static int pm_dbg_open(struct inode *inode, struct file *file)
> +{
> + switch ((int)inode->i_private) {
> + case DEBUG_FILE_COUNTERS:
> + return single_open(file, pm_dbg_show_counters,
> + &inode->i_private);
> + case DEBUG_FILE_TIMERS:
> + default:
> + return single_open(file, pm_dbg_show_timers,
> + &inode->i_private);
> + };
> +}
> +
> +static const struct file_operations debug_fops = {
> + .open = pm_dbg_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release= single_release,
> +};
> +
> +static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> +{
> + int i;
> + s64 t;
> + struct timespec now;
> +
> +
RE: [PATCH 2/2] OMAP2/3 GPTIMER: skip unnecessary TLDR write during non-autoreload
> omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load);
> - omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
> omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
> }
I seem to recall there was a missed interrupt condition which this worked
around.
IIRC, the original code didn't bother with the load I added back as a work
around as a way to get posted mode working.
Regards,
Richard W.
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
[patch 2.6.27-omap-git+ 6/5] twl4030 MMC card detction
From: David Brownell <[EMAIL PROTECTED]>
Replace stubbed-out card-detect support for twl4030 GPIOs with
a simpler platform_data mechanism. As before, no current users.
Sanity tested by enabling this on Beagle; it booted OK with
root on MMC.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/twl4030-gpio.c | 52 +-
include/linux/i2c/twl4030.h |3 ++
2 files changed, 15 insertions(+), 40 deletions(-)
--- a/drivers/gpio/twl4030-gpio.c
+++ b/drivers/gpio/twl4030-gpio.c
@@ -46,8 +46,6 @@
* intended to support multiple hosts.
*
* There are also two LED pins used sometimes as output-only GPIOs.
- *
- * FIXME code currently only handles the first IRQ line.
*/
@@ -235,41 +233,6 @@ int twl4030_set_gpio_debounce(int gpio,
}
EXPORT_SYMBOL(twl4030_set_gpio_debounce);
-#if 0
-/*
- * Configure Card detect for GPIO pin on TWL4030
- *
- * This means: VMMC1 or VMMC2 is enabled or disabled based
- * on the status of GPIO-0 or GPIO-1 pins (respectively).
- */
-int twl4030_set_gpio_card_detect(int gpio, int enable)
-{
- u8 reg = 0;
- u8 msk = (1 << gpio);
- int ret = 0;
-
- /* Only GPIO 0 or 1 can be used for CD feature.. */
- if (unlikely((gpio >= TWL4030_GPIO_MAX)
- || !(gpio_usage_count & BIT(gpio))
- || (gpio >= TWL4030_GPIO_MAX_CD))) {
- return -EPERM;
- }
-
- mutex_lock(&gpio_lock);
- ret = gpio_twl4030_read(REG_GPIO_CTRL);
- if (ret >= 0) {
- if (enable)
- reg = (u8) (ret | msk);
- else
- reg = (u8) (ret & ~msk);
-
- ret = gpio_twl4030_write(REG_GPIO_CTRL, reg);
- }
- mutex_unlock(&gpio_lock);
- return ret;
-}
-#endif
-
/*--*/
static int twl_request(struct gpio_chip *chip, unsigned offset)
@@ -317,9 +280,18 @@ static int twl_request(struct gpio_chip
}
/* on first use, turn GPIO module "on" */
- if (!gpio_usage_count)
- status = gpio_twl4030_write(REG_GPIO_CTRL,
- MASK_GPIO_CTRL_GPIO_ON);
+ if (!gpio_usage_count) {
+ struct twl4030_gpio_platform_data *pdata;
+ u8 value = MASK_GPIO_CTRL_GPIO_ON;
+
+ /* optionally have the first two GPIOs switch vMMC1
+* and vMMC2 power supplies based on card presence.
+*/
+ pdata = chip->dev->platform_data;
+ value |= pdata->mmc_cd & 0x03;
+
+ status = gpio_twl4030_write(REG_GPIO_CTRL, value);
+ }
if (!status)
gpio_usage_count |= (0x1 << offset);
--- a/include/linux/i2c/twl4030.h
+++ b/include/linux/i2c/twl4030.h
@@ -231,6 +231,9 @@ struct twl4030_gpio_platform_data {
/* package the two LED signals as output-only GPIOs? */
booluse_leds;
+ /* gpio-n should control VMMC(n+1) if BIT(n) in mmc_cd is set */
+ u8 mmc_cd;
+
/* For gpio-N, bit (1 << N) in "pullups" is set if that pullup
* should be enabled. Else, if that bit is set in "pulldowns",
* that pulldown is enabled. Don't waste power by letting any
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull request for minimal omap3 support one more time
On Tue, Oct 14, 2008 at 10:19:08AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <[EMAIL PROTECTED]> [081013 09:15]: > > There's something wrong with one of the sets I've pulled from you: > > > > arch/arm/mach-omap2/mcbsp.c:253: error: ???INT_24XX_MCBSP3_IRQ_RX??? > > undeclared here (not in a function) > > arch/arm/mach-omap2/mcbsp.c:254: error: ???INT_24XX_MCBSP3_IRQ_TX??? > > undeclared here (not in a function) > > arch/arm/mach-omap2/mcbsp.c:262: error: ???INT_24XX_MCBSP4_IRQ_RX??? > > undeclared here (not in a function) > > arch/arm/mach-omap2/mcbsp.c:263: error: ???INT_24XX_MCBSP4_IRQ_TX??? > > undeclared here (not in a function) > > arch/arm/mach-omap2/mcbsp.c:271: error: ???INT_24XX_MCBSP5_IRQ_RX??? > > undeclared here (not in a function) > > arch/arm/mach-omap2/mcbsp.c:272: error: ???INT_24XX_MCBSP5_IRQ_TX??? > > undeclared here (not in a function) > > > > Please take a look and resolve ASAP. Thanks. > > Sorry for the delay, I was sitting in an airplane again. > > Here's the fix, looks like the missing McBSP irqs should have been > merged into the recent McBSP patches. > > This patch is also in your patch system as 5301/1. Thanks, that solved that problem, but there's one more to come: arch/arm/plat-omap/devices.c: In function 'omap_mcbsp_register_board_cfg': arch/arm/plat-omap/devices.c:163: error: 'OMAP_MAX_MCBSP_COUNT' undeclared (first use in this function) arch/arm/plat-omap/devices.c:163: error: (Each undeclared identifier is reported only once arch/arm/plat-omap/devices.c:163: error: for each function it appears in.) The good news is that that seems to be the last error building for LDP. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
On Tue, Oct 14, 2008 at 10:47:44AM -0700, David Brownell wrote: > On Tuesday 14 October 2008, Felipe Balbi wrote: > > I didn't quite get you here. The idea of mmc_fck is so that > > > > clk_get(dev, "mmc_fck"); > > > > works fine and returns the correct clock. If we have several fck and ick > > function names, how will we clk_get() the right one ?? > > If "dev" is an MMC device, there's no way to confuse > its "fck" and "ick" with those for, say, I2C. Right? > That's the whole point of associating logical clock > names with the device. > > And as Paul noted, if a device has several such clocks, > then it needs several such names. hmm... that's true. Forgot about matching dev as well :-p hehehe. Makes sense to me, let's use fclk and iclk then :-) The main idea then would be that clk(dev, "iclk") translates to english into "get me the interface clock of mmc device" (when dev is an mmc device, of course). -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
On Tuesday 14 October 2008, Felipe Balbi wrote: > I didn't quite get you here. The idea of mmc_fck is so that > > clk_get(dev, "mmc_fck"); > > works fine and returns the correct clock. If we have several fck and ick > function names, how will we clk_get() the right one ?? If "dev" is an MMC device, there's no way to confuse its "fck" and "ick" with those for, say, I2C. Right? That's the whole point of associating logical clock names with the device. And as Paul noted, if a device has several such clocks, then it needs several such names. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] Hook twl4030 power code into twl4030 core.
On Monday 13 October 2008, Peter 'p2' De Schrijver wrote: > +config TWL4030_POWER > + bool "Support power sequencing scripts on TWL4030/TPS659x0" > + depends on TWL4030_CORE=y Don't need "=y" for that, since the CORE is already boolean. > + help > + Say yes here if you want to use the power management features of > + the TWL4030/TPS659x0. Saying "power management features" is misleading; there are lots of PM features this doesn't cover. Just say "power sequencing scripts" here too ... and maybe add a sentence saying what such a script *is* (controlling what type of action on what type of event). > + -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Integrate the twl4030 power code into new twl4030 mfd
On Monday 13 October 2008, Peter 'p2' De Schrijver wrote: > This patchset integrates the twl4030 power code into the new > twl4030 mfd framework. The scripts will be moved to the board > specific data. This basically looks OK, assuming the previous comments get addressed. > Peter 'p2' De Schrijver (7): > Remove existing twl4030 power script code. > Add defines and data types for twl4030. > Twl4030 power code updated for new twl4030 core > Hook twl4030 power code into twl4030 core. > 3430sdp and ldp use custom twl4030 power scripts. > Generic twl4030 power script for 3430 based boards. > omap3 evm, beagle and overo use the generic twl4030 script > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] Twl4030 power code updated for new twl4030 core
On Monday 13 October 2008, Peter 'p2' De Schrijver wrote: > --- > drivers/mfd/twl4030-power.c | 270 > +++ > 1 files changed, 270 insertions(+), 0 deletions(-) I tend to agree with the comment from Felipe that moving this file from i2c/chips to mfd should be one patch. Again, the general rule about such stuff is that a patch series should preserve bisectability. Else it gets hard to use "git bisect" to track down particularly pernicious problem patterns, promptly puncturing perplexing puzzles. :) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] lp5521: move to drivers/leds
On Tue, Oct 14, 2008 at 10:19:52AM -0700, David Brownell wrote: > On Tuesday 14 October 2008, Felipe Balbi wrote: > > On Tue, Oct 14, 2008 at 08:53:28AM -0700, David Brownell wrote: > > > On Tuesday 14 October 2008, Felipe Balbi wrote: > > > > This driver should be sitting together with the other > > > > led drivers. > > > > > > ... iff it actually uses the LED framework. Which it > > > doesn't, yet, even for simple operations. > > > > Should I change the order of the patches ? The patch going to Richard is > > only the final version of it, so there wouldn't be any difference for > > him I'd say. > > The rule of thumb is to preserve bisectability. That may be less > important inside the OMAP tree. The sequencing is fine, but it'd > be less confusing to patch-at-a-time review to at least see the > comment that a *later* patch makes it use the LED framework. makes sense, I'll put a comment to patch 2. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP2/3 GPTIMER: drop redundant pending write check
omap_dm_timer_write_reg() already waits for pending writes to complete, so the extra wait in omap_dm_timer_set_load() is superfluous. Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]> Cc: Richard Woodruff <[EMAIL PROTECTED]> --- arch/arm/plat-omap/dmtimer.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 167ec2f..59be3aa 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -539,10 +539,6 @@ void omap_dm_timer_set_load(struct omap_dm_timer *timer, int autoreload, omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l); omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load); - /* REVISIT: hw feature, ttgr overtaking tldr? */ - while (readl(timer->io_base + (OMAP_TIMER_WRITE_PEND_REG & 0xff))) - cpu_relax(); - omap_dm_timer_write_reg(timer, OMAP_TIMER_TRIGGER_REG, 0); } -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP2/3 GPTIMER: minor optimizations
Hello, these patches implement a few minor optimizations on the omap_dm_timer_set_load() and omap_dm_timer_set_load_start() functions for OMAP2/3. Gory details in the patch descriptions. Tested on 2430SDP and 3430SDP. - Paul --- textdata bss dec hex filename 3099539 135104 151144 3385787 33a9bb vmlinux.3430sdp.orig 3099539 135104 151144 3385787 33a9bb vmlinux.3430sdp arch/arm/plat-omap/dmtimer.c | 11 --- 1 files changed, 4 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP2/3 GPTIMER: skip unnecessary TLDR write during non-autoreload
The GPTIMER TLDR register does not need to be written if the GPTIMER
is not in autoreload mode. This is the usual case for dynamic tick-enabled
kernels.
Simulation data indicate that skipping the read that occurs as part of
the write should save at least 300-320 ns for each GPTIMER1 timer
reprogram. (This assumes L4-Wakeup is at 19MHz and GPTIMER write
posting is enabled.) Skipping the write itself probably won't have
much impact since it should be posted on the OCP interconnect.
Tested on 2430SDP and 3430SDP.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Cc: Richard Woodruff <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/dmtimer.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 59be3aa..08028f6 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -549,14 +549,15 @@ void omap_dm_timer_set_load_start(struct omap_dm_timer
*timer, int autoreload,
u32 l;
l = omap_dm_timer_read_reg(timer, OMAP_TIMER_CTRL_REG);
- if (autoreload)
+ if (autoreload) {
l |= OMAP_TIMER_CTRL_AR;
- else
+ omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
+ } else {
l &= ~OMAP_TIMER_CTRL_AR;
+ }
l |= OMAP_TIMER_CTRL_ST;
omap_dm_timer_write_reg(timer, OMAP_TIMER_COUNTER_REG, load);
- omap_dm_timer_write_reg(timer, OMAP_TIMER_LOAD_REG, load);
omap_dm_timer_write_reg(timer, OMAP_TIMER_CTRL_REG, l);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
On Tue, Oct 14, 2008 at 11:08:48AM -0600, Paul Walmsley wrote:
> Hi Felipe,
>
> so I'll put most of my comments here.
>
> On Tue, 7 Oct 2008, Felipe Balbi wrote:
>
> > Introduce a new mechanism to omap's clk implementation to
> > associate the device with its clock during platform_device
> > registration. Also gives the clock a function name (like
> > mmc_fck, uart_fck, ehci_fck, etc) so drivers won't have to
> > care about clk names any longer.
>
> Let's make the function names shorter, like "fclk" and "iclk". That
> should make them even easier to use in situations where the device name
> itself changes, e.g., "mmc"/"hsmmc" etc. Plus the linker will be able to
> merge many them together into single constant strings. For a device with
> multiple fclks like DSS, we can use "tv_fclk" also, etc.
I didn't quite get you here. The idea of mmc_fck is so that
clk_get(dev, "mmc_fck");
works fine and returns the correct clock. If we have several fck and ick
function names, how will we clk_get() the right one ??
> > diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> > index 7bbfba2..c090f23 100644
> > --- a/arch/arm/plat-omap/clock.c
> > +++ b/arch/arm/plat-omap/clock.c
> > @@ -43,7 +43,7 @@ static struct clk_functions *arch_clock;
> > */
> > struct clk * clk_get(struct device *dev, const char *id)
> > {
> > - struct clk *p, *clk = ERR_PTR(-ENOENT);
> > + struct clk *p, *clk;
> > int idno;
> >
> > if (dev == NULL || dev->bus != &platform_bus_type)
> > @@ -53,6 +53,15 @@ struct clk * clk_get(struct device *dev, const char *id)
> >
> > mutex_lock(&clocks_mutex);
> >
> > + list_for_each_entry(clk, &clocks, node) {
> > + if (clk->function && (dev == clk->dev) &&
> > + strcmp(id, clk->function) == 0)
> > + goto found;
>
> Please avoid the gotos and use the previously-used form for returning
> success, e.g., iterate on p; if found, then assign to clk, and break.
>
> Also, is there some reason why there are two list_for_each_entry() blocks?
> Those should be merged into one.
Will do.
>
> > +
> > + if (strcmp(id, clk->name) == 0)
> > + goto found;
>
> Doesn't the following code already handle the above case?
my bad, when merging both list_for_each_entry() this will disappear.
> > +/**
>
> First, thank you for using kerneldoc. But ...
>
> > + * omap_clk_associate - associates a user to a clock so device drivers
> > don't
> > + * have to care about clock names
>
> ... Documentation/kernel-doc-nano-HOWTO.txt requires the short function
> description to fit on one line. If you need more room, please put the
> larger description after a blank line after the last argument
> documentation line (e.g., line beginning with '@').
Will fix.
>
> > + *
>
> This blank line needs to be removed per kerneldoc - "The @argument
> descriptions must begin on the very next line ..."
>
> > + * @id: clock id as defined in arch/arm/mach-omapX/clk.h
> > + * @dev: device pointer for the clock user
> > + * @f: a function for the clock (uart_[if]ck, musb_ick, ehci_[if]ck, etc)
> > + */
> > +void __init omap_clk_associate(const char *id, struct device *dev, const
> > char *f)
> > +{
> > + struct clk *clk = clk_get(NULL, id);
> > +
> > + if (!dev || !clk || !IS_ERR(clk_get(dev, f)))
> > + return;
>
> Please break the clk_get() test above out into its own statement, and
> clk_put() it before returning.
ok.
> There needs to be a test before these lines to ensure that some driver has
> not already associated a function with this clock, or a device with this
> clock, and to WARN_ON(1) if it has.
sounds good.
> But there seems to be a deeper problem. What happens when multiple device
> drivers want to associate to the same clock? osc_ck is the pathological
> case. Seems like you'll need a different data structure, like a list, to
> store in the struct clk.
Yeah, have to think about that, but then again, how can several users
concurrently enable and disable the same clock ?
I mean, imagine driver A clk_enable(osc_ck) and while needing that
clock, driver B clk_disable(osc_ck). That would break driver A, right ?
How is omap clk fw handling that case right now ? I'd say we should have
one user per clk and in the case of osc_ck, that would be a clk input
for generating another clk, or something like that, so driver A can
clk_enable(osc_ck_A) and yet driver B could clk_disable(osc_ck_B) and
everything still works.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] lp5521: move to drivers/leds
On Tuesday 14 October 2008, Felipe Balbi wrote: > On Tue, Oct 14, 2008 at 08:53:28AM -0700, David Brownell wrote: > > On Tuesday 14 October 2008, Felipe Balbi wrote: > > > This driver should be sitting together with the other > > > led drivers. > > > > ... iff it actually uses the LED framework. Which it > > doesn't, yet, even for simple operations. > > Should I change the order of the patches ? The patch going to Richard is > only the final version of it, so there wouldn't be any difference for > him I'd say. The rule of thumb is to preserve bisectability. That may be less important inside the OMAP tree. The sequencing is fine, but it'd be less confusing to patch-at-a-time review to at least see the comment that a *later* patch makes it use the LED framework. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull request for minimal omap3 support one more time
* Russell King - ARM Linux <[EMAIL PROTECTED]> [081013 09:15]: > On Fri, Oct 10, 2008 at 02:35:34PM +0300, Tony Lindgren wrote: > > * Tony Lindgren <[EMAIL PROTECTED]> [081010 12:41]: > > > * Tony Lindgren <[EMAIL PROTECTED]> [081010 12:15]: > > > > * Russell King - ARM Linux <[EMAIL PROTECTED]> [081010 11:42]: > > > > > On Thu, Oct 09, 2008 at 06:17:25PM +0300, Tony Lindgren wrote: > > > > > > Sure, I'll post a minimal LDP patch separately tomorrow. I don't > > > > > > have > > > > > > an LDP so I can't verify it boots though. > > > > > > > > > > Unfortunately, Linus has been unpredictable, and released 2.6.27 last > > > > > night, rather than the usual one week after -rc9. > > > > > > > > > > What this means is that the merge window is now open, and I shouldn't > > > > > be accepting anything else into my kernel tree. > > > > > > > > > > However, if you can get LDP in by this evening, I'll pull it into the > > > > > tree. That will be the final devel code merged into my tree for > > > > > 2.6.28. > > > > > > > > Sure. Here's the minimal board patch for LDP with it's defconfig > > > > in the following mail. Also added to the omap3-upstream queue. > > > > > > Here's the defconfig. > > > > And here's the updated pull request for you with the LDP patches added. > > > > I also changed the title of the Overo patches to say OMAP3 instead of > > OMAP2 for consistency. > > > > Note that this will also pull the already posted omap2-upstream as > > omap3-upstream is based on that. > > There's something wrong with one of the sets I've pulled from you: > > arch/arm/mach-omap2/mcbsp.c:253: error: ‘INT_24XX_MCBSP3_IRQ_RX’ undeclared > here (not in a function) > arch/arm/mach-omap2/mcbsp.c:254: error: ‘INT_24XX_MCBSP3_IRQ_TX’ undeclared > here (not in a function) > arch/arm/mach-omap2/mcbsp.c:262: error: ‘INT_24XX_MCBSP4_IRQ_RX’ undeclared > here (not in a function) > arch/arm/mach-omap2/mcbsp.c:263: error: ‘INT_24XX_MCBSP4_IRQ_TX’ undeclared > here (not in a function) > arch/arm/mach-omap2/mcbsp.c:271: error: ‘INT_24XX_MCBSP5_IRQ_RX’ undeclared > here (not in a function) > arch/arm/mach-omap2/mcbsp.c:272: error: ‘INT_24XX_MCBSP5_IRQ_TX’ undeclared > here (not in a function) > > Please take a look and resolve ASAP. Thanks. Sorry for the delay, I was sitting in an airplane again. Here's the fix, looks like the missing McBSP irqs should have been merged into the recent McBSP patches. This patch is also in your patch system as 5301/1. Tony From: Tony Lindgren <[EMAIL PROTECTED]> Date: Tue, 14 Oct 2008 10:07:04 -0700 Subject: [PATCH] ARM: OMAP: Add missing irq defines Some McBSP irq defines were missing that should have been added with the earlier McBSP patches. Add the missing McBSP irqs, and a few other missing irqs as defined in linux-omap tree. Also add a blank line to separate irq defines from the irq line calculations. Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> --- a/arch/arm/plat-omap/include/mach/irqs.h +++ b/arch/arm/plat-omap/include/mach/irqs.h @@ -266,6 +266,8 @@ #define INT_24XX_GPTIMER11 47 #define INT_24XX_GPTIMER12 48 #define INT_24XX_SHA1MD5 51 +#define INT_24XX_MCBSP4_IRQ_TX 54 +#define INT_24XX_MCBSP4_IRQ_RX 55 #define INT_24XX_I2C1_IRQ 56 #define INT_24XX_I2C2_IRQ 57 #define INT_24XX_HDQ_IRQ 58 @@ -284,7 +286,22 @@ #define INT_24XX_USB_IRQ_HGEN 78 #define INT_24XX_USB_IRQ_HSOF 79 #define INT_24XX_USB_IRQ_OTG 80 +#define INT_24XX_MCBSP5_IRQ_TX 81 +#define INT_24XX_MCBSP5_IRQ_RX 82 #define INT_24XX_MMC_IRQ 83 +#define INT_24XX_MMC2_IRQ 86 +#define INT_24XX_MCBSP3_IRQ_TX 89 +#define INT_24XX_MCBSP3_IRQ_RX 90 +#define INT_24XX_SPI3_IRQ 91 + +#define INT_243X_MCBSP2_IRQ 16 +#define INT_243X_MCBSP3_IRQ 17 +#define INT_243X_MCBSP4_IRQ 18 +#define INT_243X_MCBSP5_IRQ 19 +#define INT_243X_MCBSP1_IRQ 64 +#define INT_243X_HS_USB_MC 92 +#define INT_243X_HS_USB_DMA 93 +#define INT_243X_CARKIT_IRQ 94 #define INT_34XX_BENCH_MPU_EMUL 3 #define INT_34XX_ST_MCBSP2_IRQ 4 @@ -321,6 +338,7 @@ #define INT_34XX_PARTHASH_IRQ 79 #define INT_34XX_MMC3_IRQ 94 #define INT_34XX_GPT12_IRQ 95 + /* Max. 128 level 2 IRQs (OMAP1610), 192 GPIOs (OMAP730) and * 16 MPUIO lines */ #define OMAP_MAX_GPIO_LINES 192
Re: [PATCH 3/8] lp5521: move to drivers/leds
On Tue, Oct 14, 2008 at 08:53:28AM -0700, David Brownell wrote: > On Tuesday 14 October 2008, Felipe Balbi wrote: > > This driver should be sitting together with the other > > led drivers. > > ... iff it actually uses the LED framework. Which it > doesn't, yet, even for simple operations. Should I change the order of the patches ? The patch going to Richard is only the final version of it, so there wouldn't be any difference for him I'd say. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] leds: lp5521: register separate leds
On Tue, Oct 14, 2008 at 08:55:21AM -0700, David Brownell wrote: > On Tuesday 14 October 2008, Felipe Balbi wrote: > > @@ -23,7 +24,9 @@ > > #include > > #include > > #include > > +#include > > #include > > +#include > > > > #define LP5521_DRIVER_NAME "lp5521" > > > > Ah, *here* it converts to use the LED framework. The patch > comment should probably focus on that ... "separate leds" is > just an artifact of that conversion, as I interpret things. Sure, I'll update and resend tomorrow. The ambient light sensor, I'll drop from now and leave it pending until we have a good answer for where it should go. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: introduce omap_clk_associate
Hi Felipe,
so I'll put most of my comments here.
On Tue, 7 Oct 2008, Felipe Balbi wrote:
> Introduce a new mechanism to omap's clk implementation to
> associate the device with its clock during platform_device
> registration. Also gives the clock a function name (like
> mmc_fck, uart_fck, ehci_fck, etc) so drivers won't have to
> care about clk names any longer.
Let's make the function names shorter, like "fclk" and "iclk". That
should make them even easier to use in situations where the device name
itself changes, e.g., "mmc"/"hsmmc" etc. Plus the linker will be able to
merge many them together into single constant strings. For a device with
multiple fclks like DSS, we can use "tv_fclk" also, etc.
> With this mechanism we can also be sure drivers won't be able
> to clk_get the wrong clk (only true when we move all drivers
> to this new mechanism and drop the old ones).
>
> Clk's function names will be defined as they come necessary
> but let's try to keep it as simple as possible.
>
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> arch/arm/plat-omap/clock.c | 38 +-
> arch/arm/plat-omap/include/mach/clock.h |6 +
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
> index 7bbfba2..c090f23 100644
> --- a/arch/arm/plat-omap/clock.c
> +++ b/arch/arm/plat-omap/clock.c
> @@ -43,7 +43,7 @@ static struct clk_functions *arch_clock;
> */
> struct clk * clk_get(struct device *dev, const char *id)
> {
> - struct clk *p, *clk = ERR_PTR(-ENOENT);
> + struct clk *p, *clk;
> int idno;
>
> if (dev == NULL || dev->bus != &platform_bus_type)
> @@ -53,6 +53,15 @@ struct clk * clk_get(struct device *dev, const char *id)
>
> mutex_lock(&clocks_mutex);
>
> + list_for_each_entry(clk, &clocks, node) {
> + if (clk->function && (dev == clk->dev) &&
> + strcmp(id, clk->function) == 0)
> + goto found;
Please avoid the gotos and use the previously-used form for returning
success, e.g., iterate on p; if found, then assign to clk, and break.
Also, is there some reason why there are two list_for_each_entry() blocks?
Those should be merged into one.
> +
> + if (strcmp(id, clk->name) == 0)
> + goto found;
Doesn't the following code already handle the above case?
> + }
> +
> list_for_each_entry(p, &clocks, node) {
> if (p->id == idno &&
> strcmp(id, p->name) == 0 && try_module_get(p->owner)) {
> @@ -64,10 +73,14 @@ struct clk * clk_get(struct device *dev, const char *id)
> list_for_each_entry(p, &clocks, node) {
> if (strcmp(id, p->name) == 0 && try_module_get(p->owner)) {
> clk = p;
> - break;
> + goto found;
> }
> }
>
> + mutex_unlock(&clocks_mutex);
> +
> + return ERR_PTR(-ENOENT);
the above two lines will then become unnecessary.
> +
> found:
> mutex_unlock(&clocks_mutex);
>
> @@ -75,6 +88,27 @@ found:
> }
> EXPORT_SYMBOL(clk_get);
>
> +/**
First, thank you for using kerneldoc. But ...
> + * omap_clk_associate - associates a user to a clock so device drivers don't
> + * have to care about clock names
... Documentation/kernel-doc-nano-HOWTO.txt requires the short function
description to fit on one line. If you need more room, please put the
larger description after a blank line after the last argument
documentation line (e.g., line beginning with '@').
> + *
This blank line needs to be removed per kerneldoc - "The @argument
descriptions must begin on the very next line ..."
> + * @id: clock id as defined in arch/arm/mach-omapX/clk.h
> + * @dev: device pointer for the clock user
> + * @f: a function for the clock (uart_[if]ck, musb_ick, ehci_[if]ck, etc)
> + */
> +void __init omap_clk_associate(const char *id, struct device *dev, const
> char *f)
> +{
> + struct clk *clk = clk_get(NULL, id);
> +
> + if (!dev || !clk || !IS_ERR(clk_get(dev, f)))
> + return;
Please break the clk_get() test above out into its own statement, and
clk_put() it before returning.
> +
> + clk->function = f;
> + clk->dev = dev;
There needs to be a test before these lines to ensure that some driver has
not already associated a function with this clock, or a device with this
clock, and to WARN_ON(1) if it has.
But there seems to be a deeper problem. What happens when multiple device
drivers want to associate to the same clock? osc_ck is the pathological
case. Seems like you'll need a different data structure, like a list, to
store in the struct clk.
> +
> + clk_put(clk);
> +};
> +
> int clk_enable(struct clk *clk)
> {
> unsigned long flags;
> diff --git a/arch/arm/plat-omap/include/mach/clock.h
> b/arch/arm/plat-omap/include/mach/clock.h
> index
Re: [PATCH 1/3] [RFC] clk: introduce clk_associate
Hi, between omap_clk_associate() and vclk, my preference is for the omap_clk_associate() approach. The core problem is that the vclk patches create clocks with multiple parents in a way that is hidden from the clock framework. This causes both semantic and practical problems. Semantically, the patches cause the meaning of set_rate() and set_parent() to be confused, and any driver that wants to call set_parent() or set_rate() on those clocks will need to have their own custom functions for those operations. I'd like to keep the amount of that custom code minimized. In practical terms, the vclk code will cause spinlock recursion bugs like the ones that currently exist with the McBSP driver: http://marc.info/?l=linux-omap&m=122310205615940&w=2 since vclks will call clk_enable()/disable()/set_rate()/etc. inside the clockfw_lock spinlock. Using the vclk patches also means that the number of custom clocks will explode, as each driver is likely to define at least one custom clock. [ eventually, we'll need to deal with the multiple parent issue, if for no other reason than to fix usecounting for clocks like dss_ick. But it will need to be handled by the clock framework code itself. And this problem is pretty low on the priority list... ] So between the two, I'd like to see omap_clk_associate() integrated. I have some comments to post on Felipe's code; once those are addressed, hopefully we can merge it. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] 3430sdp and ldp use custom twl4030 power scripts.
On Monday 13 October 2008, Peter 'p2' De Schrijver wrote: > On Fri, Oct 10, 2008 at 10:53:22AM -0700, ext David Brownell wrote: > > On Friday 10 October 2008, Peter 'p2' De Schrijver wrote: > > > The TI 3430dsp and ldp boards have a custom power script. > > > > And for those of us less conversant in this tech ... could > > you summarize, in words of one syllable or less, just what > > these scripts do that's different from the "generic" one? > > And why the generic script is inappropriate? > > > > These scripts are already in linux-omap, so this just maintaining > existing functionality. I realize that ... > I don't have access to an LDP, and have no idea > why they don't use the generic script. Hmm. Maybe someone from TI can explain. I suspect part of it is that several of the other boards aren't actually battery powered, but it's unclear whether that's the whole story. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] omap3 evm, beagle and overo use the generic twl4030 script
On Monday 13 October 2008, Peter 'p2' De Schrijver wrote: > > > +extern struct twl4030_power_data generic3430_t2scripts_data; > > > > Such "extern" decls should as a rule be in header files... > > > > In this case the rule is appropriate, since you've got the > > same decl in three different places. That's about two times > > more often than I'm comfortable making exceptions to such a > > rule ... :) > > Please suggest an appropriate header file. I couldn't find one and > creating a header file for a single extern declaration ? Maybe arch/arm/mach-omap2/pm.h would be the most natural fit. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
On Tuesday 14 October 2008, Felipe Balbi wrote: > > > Nack. Light sensors have nothing to do with hardware monitoring. > > > > The only light sensor driver in the kernel tree at the moment > > is drivers/i2c/chips/tsl2550.c. But I'm not very happy with this > > either, as my ultimate goal is to delete the drivers/i2c/chips > > directory completely. So we should find a new home for light sensors. > > and that's why I'm moving nokia drivers out of drivers/i2c/chips > directory. > > > Maybe they should go into the new "industrial I/O" subsystem. Or if > > not, their own drivers/sensors/light directory. > > Well, could be. We might need someone else, like Andrew, to answer that > question. My two cents: leave them where they are until a "good" answer exists. Or if drivers/i2c/chips is sufficiently annoying ... drivers/misc may be a good interim site. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] leds: lp5521: register separate leds
On Tuesday 14 October 2008, Felipe Balbi wrote: > @@ -23,7 +24,9 @@ > #include > #include > #include > +#include > #include > +#include > > #define LP5521_DRIVER_NAME "lp5521" > Ah, *here* it converts to use the LED framework. The patch comment should probably focus on that ... "separate leds" is just an artifact of that conversion, as I interpret things. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] lp5521: move to drivers/leds
On Tuesday 14 October 2008, Felipe Balbi wrote: > This driver should be sitting together with the other > led drivers. ... iff it actually uses the LED framework. Which it doesn't, yet, even for simple operations. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
On Tue, Oct 14, 2008 at 07:30:58AM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > > Why not just skipping the waiting and returning error pretending user > > really sent a signal? > > Better than nothing, but because signal_pending() isn't actually true, > upper layers wil behave differently. If they check... For example omap_hdq_break() can be interrupted and omap_hdq_probe() does not check its return value. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Add pm-debug counters
This patch provides the debugfs entries and a function which will be called
by the PM code to register the time spent per domain per state.
Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm-debug.c| 175 +
arch/arm/mach-omap2/pm.h |2 +
2 files changed, 177 insertions(+)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 0b5c044..4ba6cec 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -29,6 +29,8 @@
#include
#include
+#include
+#include
#include "prm.h"
#include "cm.h"
@@ -288,4 +290,177 @@ void omap2_pm_dump(int mode, int resume, unsigned int us)
printk("%-20s: 0x%08x\n", regs[i].name, regs[i].val);
}
+#ifdef CONFIG_DEBUG_FS
+#include
+#include
+
+struct dentry *pm_dbg_dir;
+
+static int pm_dbg_init_done;
+
+enum {
+ DEBUG_FILE_COUNTERS = 0,
+ DEBUG_FILE_TIMERS,
+};
+
+static const char pwrdm_state_names[][4] = {
+ "OFF",
+ "RET",
+ "INA",
+ "ON"
+};
+
+void pm_dbg_update_time(struct powerdomain *pwrdm, int prev)
+{
+ s64 t;
+ struct timespec now;
+
+ if (!pm_dbg_init_done)
+ return ;
+
+ /* Update timer for previous state */
+ getnstimeofday(&now);
+ t = timespec_to_ns(&now);
+
+ pwrdm->state_timer[prev] += t - pwrdm->timer;
+
+ pwrdm->timer = t;
+}
+
+static int clkdm_dbg_show_counter(struct clockdomain *clkdm, void *user)
+{
+ struct seq_file *s = (struct seq_file *)user;
+
+ if (strcmp(clkdm->name, "emu_clkdm") == 0 ||
+ strcmp(clkdm->name, "wkup_clkdm") == 0)
+ return 0;
+
+ seq_printf(s, "%s->%s (%d)", clkdm->name,
+ clkdm->pwrdm.ptr->name,
+ atomic_read(&clkdm->usecount));
+ seq_printf(s, "\n");
+
+ return 0;
+}
+
+static int pwrdm_dbg_show_counter(struct powerdomain *pwrdm, void *user)
+{
+ struct seq_file *s = (struct seq_file *)user;
+ int i;
+
+ if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
+ strcmp(pwrdm->name, "wkup_pwrdm") == 0)
+ return 0;
+
+ if (pwrdm->state != pwrdm_read_pwrst(pwrdm))
+ printk(KERN_ERR "pwrdm state mismatch(%s) %d != %d\n",
+ pwrdm->name, pwrdm->state, pwrdm_read_pwrst(pwrdm));
+
+ seq_printf(s, "%s (%s)", pwrdm->name,
+ pwrdm_state_names[pwrdm->state]);
+ for (i = 0; i < 4; i++)
+ seq_printf(s, ",%s:%d", pwrdm_state_names[i],
+ pwrdm->state_counter[i]);
+
+ seq_printf(s, "\n");
+
+ return 0;
+}
+
+static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user)
+{
+ struct seq_file *s = (struct seq_file *)user;
+ int i;
+
+ if (strcmp(pwrdm->name, "emu_pwrdm") == 0 ||
+ strcmp(pwrdm->name, "wkup_pwrdm") == 0)
+ return 0;
+
+ pwrdm_state_switch(pwrdm);
+
+ seq_printf(s, "%s (%s)", pwrdm->name,
+ pwrdm_state_names[pwrdm->state]);
+
+ for (i = 0; i < 4; i++)
+ seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
+ pwrdm->state_timer[i]);
+
+ seq_printf(s, "\n");
+
+ return 0;
+}
+
+static void pm_dbg_show_counters(struct seq_file *s, void *unused)
+{
+ pwrdm_for_each(pwrdm_dbg_show_counter, s);
+ clkdm_for_each(clkdm_dbg_show_counter, s);
+}
+
+static void pm_dbg_show_timers(struct seq_file *s, void *unused)
+{
+ pwrdm_for_each(pwrdm_dbg_show_timer, s);
+}
+
+static int pm_dbg_open(struct inode *inode, struct file *file)
+{
+ switch ((int)inode->i_private) {
+ case DEBUG_FILE_COUNTERS:
+ return single_open(file, pm_dbg_show_counters,
+ &inode->i_private);
+ case DEBUG_FILE_TIMERS:
+ default:
+ return single_open(file, pm_dbg_show_timers,
+ &inode->i_private);
+ };
+}
+
+static const struct file_operations debug_fops = {
+ .open = pm_dbg_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release= single_release,
+};
+
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
+{
+ int i;
+ s64 t;
+ struct timespec now;
+
+ getnstimeofday(&now);
+ t = timespec_to_ns(&now);
+
+ for (i = 0; i < 4; i++)
+ pwrdm->state_timer[i] = 0;
+
+ pwrdm->timer = t;
+
+ return 0;
+}
+
+static int __init pm_dbg_init(void)
+{
+ struct dentry *d;
+
+ printk(KERN_INFO "pm_dbg_init()\n");
+
+ d = debugfs_create_dir("pm_debug", NULL);
+ if (IS_ERR(d))
+ return PTR_ERR(d);
+
+ (void) debugfs_create_file("count", S_IRUGO,
+ d, (void *)DEBUG_FILE_COUNTERS, &debug_fops);
+ (void) debugfs_create_fi
[PATCH 0/3] debugfs entries for PM counters
This patchset adds 2 debugfs entries for power management counters. pm_debug/count indicates how many times each powerdomain entered each state (On, Inactive, Retention, Off). pm_debug/time indicates how much time each powerdomain spent per state. Peter 'p2' De Schrijver (3): Add closures to clkdm_for_each. Add pm-debug counters Hook into powerdomain code arch/arm/mach-omap2/clockdomain.c |5 +- arch/arm/mach-omap2/pm-debug.c| 175 + arch/arm/mach-omap2/pm.h |2 + arch/arm/mach-omap2/pm34xx.c |8 +- arch/arm/mach-omap2/powerdomain.c | 24 +++- arch/arm/plat-omap/include/mach/clockdomain.h |3 +- arch/arm/plat-omap/include/mach/powerdomain.h |8 +- 7 files changed, 209 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Add closures to clkdm_for_each and pwrdm_for_each.
First add some infrastructure to easily iterate over clock and power domains.
Also add extra fields to the powerdomain struct to keep the time info.
Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/clockdomain.c |5 +++--
arch/arm/mach-omap2/pm34xx.c |8
arch/arm/plat-omap/include/mach/clockdomain.h |3 ++-
arch/arm/plat-omap/include/mach/powerdomain.h |8 +++-
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index 5249fe8..b0b5885 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -295,7 +295,8 @@ struct clockdomain *clkdm_lookup(const char *name)
* anything else to indicate failure; or -EINVAL if the function pointer
* is null.
*/
-int clkdm_for_each(int (*fn)(struct clockdomain *clkdm))
+int clkdm_for_each(int (*fn)(struct clockdomain *clkdm, void *user),
+ void *user)
{
struct clockdomain *clkdm;
int ret = 0;
@@ -305,7 +306,7 @@ int clkdm_for_each(int (*fn)(struct clockdomain *clkdm))
mutex_lock(&clkdm_mutex);
list_for_each_entry(clkdm, &clkdm_list, node) {
- ret = (*fn)(clkdm);
+ ret = (*fn)(clkdm, user);
if (ret)
break;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 1fbb690..be69839 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -518,7 +518,7 @@ static void __init prcm_setup_regs(void)
OCP_MOD, OMAP2_PRM_IRQENABLE_MPU_OFFSET);
}
-static int __init pwrdms_setup(struct powerdomain *pwrdm)
+static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
{
struct power_state *pwrst;
@@ -538,7 +538,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm)
return set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
}
-static int __init clkdms_setup(struct clockdomain *clkdm)
+static int __init clkdms_setup(struct clockdomain *clkdm, void *unused)
{
omap2_clkdm_allow_idle(clkdm);
return 0;
@@ -564,13 +564,13 @@ int __init omap3_pm_init(void)
goto err1;
}
- ret = pwrdm_for_each(pwrdms_setup);
+ ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR "Failed to setup powerdomains\n");
goto err2;
}
- (void) clkdm_for_each(clkdms_setup);
+ (void) clkdm_for_each(clkdms_setup, NULL);
mpu_pwrdm = pwrdm_lookup("mpu_pwrdm");
if (mpu_pwrdm == NULL) {
diff --git a/arch/arm/plat-omap/include/mach/clockdomain.h
b/arch/arm/plat-omap/include/mach/clockdomain.h
index b9d0dd2..99ebd88 100644
--- a/arch/arm/plat-omap/include/mach/clockdomain.h
+++ b/arch/arm/plat-omap/include/mach/clockdomain.h
@@ -95,7 +95,8 @@ int clkdm_register(struct clockdomain *clkdm);
int clkdm_unregister(struct clockdomain *clkdm);
struct clockdomain *clkdm_lookup(const char *name);
-int clkdm_for_each(int (*fn)(struct clockdomain *clkdm));
+int clkdm_for_each(int (*fn)(struct clockdomain *clkdm, void *user),
+ void *user);
struct powerdomain *clkdm_get_pwrdm(struct clockdomain *clkdm);
void omap2_clkdm_allow_idle(struct clockdomain *clkdm);
diff --git a/arch/arm/plat-omap/include/mach/powerdomain.h
b/arch/arm/plat-omap/include/mach/powerdomain.h
index 52663fc..6271d85 100644
--- a/arch/arm/plat-omap/include/mach/powerdomain.h
+++ b/arch/arm/plat-omap/include/mach/powerdomain.h
@@ -119,6 +119,11 @@ struct powerdomain {
int state;
unsigned state_counter[4];
+
+#ifdef CONFIG_PM_DEBUG
+ s64 timer;
+ s64 state_timer[4];
+#endif
};
@@ -128,7 +133,8 @@ int pwrdm_register(struct powerdomain *pwrdm);
int pwrdm_unregister(struct powerdomain *pwrdm);
struct powerdomain *pwrdm_lookup(const char *name);
-int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm));
+int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm, void *user),
+ void *user);
int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm);
int pwrdm_del_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm);
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Hook into powerdomain code
Make the powerdomain code call the new hook for updating the time.
Also implement the updated pwrdm_for_each.
Signed-off-by: Peter 'p2' De Schrijver <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/powerdomain.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 349b7ab..0334609 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -35,6 +35,8 @@
#include
#include
+#include "pm.h"
+
enum {
PWRDM_STATE_NOW = 0,
PWRDM_STATE_PREV,
@@ -134,19 +136,21 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
if (state != prev)
pwrdm->state_counter[state]++;
+ pm_dbg_update_time(pwrdm, prev);
+
pwrdm->state = state;
return 0;
}
-static int _pwrdm_pre_transition_cb(struct powerdomain *pwrdm)
+static int _pwrdm_pre_transition_cb(struct powerdomain *pwrdm, void *unused)
{
pwrdm_clear_all_prev_pwrst(pwrdm);
_pwrdm_state_switch(pwrdm, PWRDM_STATE_NOW);
return 0;
}
-static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm)
+static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused)
{
_pwrdm_state_switch(pwrdm, PWRDM_STATE_PREV);
return 0;
@@ -179,9 +183,12 @@ void pwrdm_init(struct powerdomain **pwrdm_list)
{
struct powerdomain **p = NULL;
- if (pwrdm_list)
- for (p = pwrdm_list; *p; p++)
+ if (pwrdm_list) {
+ for (p = pwrdm_list; *p; p++) {
pwrdm_register(*p);
+ _pwrdm_setup(*p);
+ }
+ }
}
/**
@@ -279,7 +286,8 @@ struct powerdomain *pwrdm_lookup(const char *name)
* anything else to indicate failure; or -EINVAL if the function
* pointer is null.
*/
-int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm))
+int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm, void *user),
+ void *user)
{
struct powerdomain *temp_pwrdm;
unsigned long flags;
@@ -290,7 +298,7 @@ int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm))
read_lock_irqsave(&pwrdm_rwlock, flags);
list_for_each_entry(temp_pwrdm, &pwrdm_list, node) {
- ret = (*fn)(temp_pwrdm);
+ ret = (*fn)(temp_pwrdm, user);
if (ret)
break;
}
@@ -1195,13 +1203,13 @@ int pwrdm_clk_state_switch(struct clk *clk)
int pwrdm_pre_transition(void)
{
- pwrdm_for_each(_pwrdm_pre_transition_cb);
+ pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
return 0;
}
int pwrdm_post_transition(void)
{
- pwrdm_for_each(_pwrdm_post_transition_cb);
+ pwrdm_for_each(_pwrdm_post_transition_cb, NULL);
return 0;
}
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
On Tue, Oct 14, 2008 at 04:14:26PM +0200, ext Jean Delvare wrote: > I've implied a sysfs interface with my tsl2550 driver, essentially > derived from the hwmon sysfs interface. I hope you followed it in your > driver if possible. When these drivers have a new home, we can document > the sysfs interface. Or, if these drivers end up in the industrial I/O > subsystem, maybe a completely different interface will be used instead > (but then it's in Jonathan's hands.) Hmm, I didn't really write the driver, I'm just fixing a few stuff to prepare for submission to mainline. If we end up with your sysfs interface, I can change that, no problem. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
> On Tue, 14 Oct 2008 17:42:49 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > Hi. > > On Tue, Oct 14, 2008 at 05:50:02AM -0700, Andrew Morton ([EMAIL PROTECTED]) > wrote: > > I think it's reasonable to permit the driver's operations to be interrupted > > in this manner. It's done in quite a few other places. But the problem is > > actually *testing* it. > > Why not just skipping the waiting and returning error pretending user > really sent a signal? Better than nothing, but because signal_pending() isn't actually true, upper layers wil behave differently. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
On Tue, 14 Oct 2008 16:52:30 +0300, Felipe Balbi wrote:
> On Tue, Oct 14, 2008 at 03:38:24PM +0200, ext Jean Delvare wrote:
> > Hi Felipe,
> >
> > On Tue, 14 Oct 2008 16:01:38 +0300, Felipe Balbi wrote:
> > > Moving the driver to where it should sit. No functional
> > > changes.
> > >
> > > Cc: Jean Delvare <[EMAIL PROTECTED]>
> > > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> > > ---
> > > drivers/hwmon/Kconfig | 10 ++
> > > drivers/hwmon/Makefile |1 +
> > > drivers/{i2c/chips => hwmon}/tsl2563.c |2 +-
> > > drivers/i2c/chips/Kconfig | 10 --
> > > drivers/i2c/chips/Makefile |1 -
> > > 5 files changed, 12 insertions(+), 12 deletions(-)
> > > rename drivers/{i2c/chips => hwmon}/tsl2563.c (99%)
> > >
> > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > > index 390c6fa..dabc148 100644
> > > --- a/drivers/hwmon/Kconfig
> > > +++ b/drivers/hwmon/Kconfig
> > > @@ -670,6 +670,16 @@ config SENSORS_THMC50
> > > This driver can also be built as a module. If so, the module
> > > will be called thmc50.
> > >
> > > +config SENSORS_TSL2563
> > > + tristate "Taos TSL2563 ambient light sensor"
> > > + depends on I2C && HWMON
> > > + help
> > > + If you say yes here you get support for the Taos TSL2563
> > > + ambient light sensor.
> > > +
> > > + This driver can also be built as a module. If so, the module
> > > + will be called tsl2563.
> > > +
> > > config SENSORS_VIA686A
> > > tristate "VIA686A"
> > > depends on PCI
> >
> > Nack. Light sensors have nothing to do with hardware monitoring.
> >
> > The only light sensor driver in the kernel tree at the moment
> > is drivers/i2c/chips/tsl2550.c. But I'm not very happy with this
> > either, as my ultimate goal is to delete the drivers/i2c/chips
> > directory completely. So we should find a new home for light sensors.
>
> and that's why I'm moving nokia drivers out of drivers/i2c/chips
> directory.
>
> > Maybe they should go into the new "industrial I/O" subsystem. Or if
> > not, their own drivers/sensors/light directory.
>
> Well, could be. We might need someone else, like Andrew, to answer that
> question.
I'd rather ask the question to Jonathan Cameron (Cc'd.)
> Andrew, do you have any comments if we should create a directory for
> light sensors ? In that case, looks like we're gonna need some
> abstraction layer, right ?
I've implied a sysfs interface with my tsl2550 driver, essentially
derived from the hwmon sysfs interface. I hope you followed it in your
driver if possible. When these drivers have a new home, we can document
the sysfs interface. Or, if these drivers end up in the industrial I/O
subsystem, maybe a completely different interface will be used instead
(but then it's in Jonathan's hands.)
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
On Tue, Oct 14, 2008 at 03:38:24PM +0200, ext Jean Delvare wrote:
> Hi Felipe,
>
> On Tue, 14 Oct 2008 16:01:38 +0300, Felipe Balbi wrote:
> > Moving the driver to where it should sit. No functional
> > changes.
> >
> > Cc: Jean Delvare <[EMAIL PROTECTED]>
> > Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> > ---
> > drivers/hwmon/Kconfig | 10 ++
> > drivers/hwmon/Makefile |1 +
> > drivers/{i2c/chips => hwmon}/tsl2563.c |2 +-
> > drivers/i2c/chips/Kconfig | 10 --
> > drivers/i2c/chips/Makefile |1 -
> > 5 files changed, 12 insertions(+), 12 deletions(-)
> > rename drivers/{i2c/chips => hwmon}/tsl2563.c (99%)
> >
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 390c6fa..dabc148 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -670,6 +670,16 @@ config SENSORS_THMC50
> > This driver can also be built as a module. If so, the module
> > will be called thmc50.
> >
> > +config SENSORS_TSL2563
> > + tristate "Taos TSL2563 ambient light sensor"
> > + depends on I2C && HWMON
> > + help
> > + If you say yes here you get support for the Taos TSL2563
> > + ambient light sensor.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called tsl2563.
> > +
> > config SENSORS_VIA686A
> > tristate "VIA686A"
> > depends on PCI
>
> Nack. Light sensors have nothing to do with hardware monitoring.
>
> The only light sensor driver in the kernel tree at the moment
> is drivers/i2c/chips/tsl2550.c. But I'm not very happy with this
> either, as my ultimate goal is to delete the drivers/i2c/chips
> directory completely. So we should find a new home for light sensors.
and that's why I'm moving nokia drivers out of drivers/i2c/chips
directory.
> Maybe they should go into the new "industrial I/O" subsystem. Or if
> not, their own drivers/sensors/light directory.
Well, could be. We might need someone else, like Andrew, to answer that
question.
Andrew, do you have any comments if we should create a directory for
light sensors ? In that case, looks like we're gonna need some
abstraction layer, right ?
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
Hi. On Tue, Oct 14, 2008 at 05:50:02AM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > I think it's reasonable to permit the driver's operations to be interrupted > in this manner. It's done in quite a few other places. But the problem is > actually *testing* it. Why not just skipping the waiting and returning error pretending user really sent a signal? -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
Hi Felipe,
On Tue, 14 Oct 2008 16:01:38 +0300, Felipe Balbi wrote:
> Moving the driver to where it should sit. No functional
> changes.
>
> Cc: Jean Delvare <[EMAIL PROTECTED]>
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/hwmon/Kconfig | 10 ++
> drivers/hwmon/Makefile |1 +
> drivers/{i2c/chips => hwmon}/tsl2563.c |2 +-
> drivers/i2c/chips/Kconfig | 10 --
> drivers/i2c/chips/Makefile |1 -
> 5 files changed, 12 insertions(+), 12 deletions(-)
> rename drivers/{i2c/chips => hwmon}/tsl2563.c (99%)
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 390c6fa..dabc148 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -670,6 +670,16 @@ config SENSORS_THMC50
> This driver can also be built as a module. If so, the module
> will be called thmc50.
>
> +config SENSORS_TSL2563
> + tristate "Taos TSL2563 ambient light sensor"
> + depends on I2C && HWMON
> + help
> + If you say yes here you get support for the Taos TSL2563
> + ambient light sensor.
> +
> + This driver can also be built as a module. If so, the module
> + will be called tsl2563.
> +
> config SENSORS_VIA686A
> tristate "VIA686A"
> depends on PCI
Nack. Light sensors have nothing to do with hardware monitoring.
The only light sensor driver in the kernel tree at the moment
is drivers/i2c/chips/tsl2550.c. But I'm not very happy with this
either, as my ultimate goal is to delete the drivers/i2c/chips
directory completely. So we should find a new home for light sensors.
Maybe they should go into the new "industrial I/O" subsystem. Or if
not, their own drivers/sensors/light directory.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] HS/EMU OMAP3 SRAM size fix
On Tue, Oct 14, 2008 at 3:23 PM, Tero Kristo <[EMAIL PROTECTED]> wrote:
> Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
> ---
> arch/arm/plat-omap/sram.c | 12 +---
> 1 files changed, 9 insertions(+), 3 deletions(-)
> mode change 100644 => 100755 arch/arm/plat-omap/sram.c
>
> diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
> old mode 100644
> new mode 100755
> index 9cfb77f..f0ac426
> --- a/arch/arm/plat-omap/sram.c
> +++ b/arch/arm/plat-omap/sram.c
> @@ -125,9 +125,15 @@ void __init omap_detect_sram(void)
>if (cpu_class_is_omap2()) {
>if (is_sram_locked()) {
>if (cpu_is_omap34xx()) {
> - omap_sram_base = OMAP3_SRAM_PUB_VA;
> - omap_sram_start = OMAP3_SRAM_PUB_PA;
> - omap_sram_size = 0x8000; /* 32K */
> + if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
> + omap_sram_base = OMAP3_SRAM_PUB_VA;
> + omap_sram_start = OMAP3_SRAM_PUB_PA;
> + omap_sram_size = 0x8000; /* 32K */
> + } else {
> + omap_sram_base = OMAP3_SRAM_PUB_VA;
> + omap_sram_start = OMAP3_SRAM_PUB_PA;
> + omap_sram_size = 0x7000; /* 28K */
> + }
It seems omap_sram_base and _start are the same, maybe have leave them
outside the if?
>} else {
>omap_sram_base = OMAP2_SRAM_PUB_VA;
>omap_sram_start = OMAP2_SRAM_PUB_PA;
> --
> 1.5.4.3
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] input: lm8323: get rid of global pdata pointer
pdata is only used during probe to initialize a few fields
from lm8323 device structure. Moving pdata pointer to probe
won't harm anybody.
Cc: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/input/keyboard/lm8323.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 72bb587..b6f464c 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -184,9 +184,6 @@ static struct lm8323_chip *pwm_to_lm8323(struct lm8323_pwm
*pwm)
}
}
-static struct lm8323_platform_data *lm8323_pdata;
-
-
#define LM8323_MAX_DATA 8
/*
@@ -673,6 +670,7 @@ static DEVICE_ATTR(disable_kp, 0644, lm8323_show_disable,
lm8323_set_disable);
static int lm8323_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+ struct lm8323_platform_data *lm8323_pdata;
struct input_dev *idev;
struct lm8323_chip *lm;
int i, err = 0;
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] tsl2563: move tsl2563 to drivers/hwmon
Moving the driver to where it should sit. No functional
changes.
Cc: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/hwmon/Kconfig | 10 ++
drivers/hwmon/Makefile |1 +
drivers/{i2c/chips => hwmon}/tsl2563.c |2 +-
drivers/i2c/chips/Kconfig | 10 --
drivers/i2c/chips/Makefile |1 -
5 files changed, 12 insertions(+), 12 deletions(-)
rename drivers/{i2c/chips => hwmon}/tsl2563.c (99%)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 390c6fa..dabc148 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -670,6 +670,16 @@ config SENSORS_THMC50
This driver can also be built as a module. If so, the module
will be called thmc50.
+config SENSORS_TSL2563
+ tristate "Taos TSL2563 ambient light sensor"
+ depends on I2C && HWMON
+ help
+ If you say yes here you get support for the Taos TSL2563
+ ambient light sensor.
+
+ This driver can also be built as a module. If so, the module
+ will be called tsl2563.
+
config SENSORS_VIA686A
tristate "VIA686A"
depends on PCI
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 2580d5d..28990a5 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o
obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o
obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
obj-$(CONFIG_SENSORS_THMC50) += thmc50.o
+obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
obj-$(CONFIG_SENSORS_VIA686A) += via686a.o
obj-$(CONFIG_SENSORS_VT1211) += vt1211.o
obj-$(CONFIG_SENSORS_VT8231) += vt8231.o
diff --git a/drivers/i2c/chips/tsl2563.c b/drivers/hwmon/tsl2563.c
similarity index 99%
rename from drivers/i2c/chips/tsl2563.c
rename to drivers/hwmon/tsl2563.c
index e05b880..afc3265 100644
--- a/drivers/i2c/chips/tsl2563.c
+++ b/drivers/hwmon/tsl2563.c
@@ -1,5 +1,5 @@
/*
- * drivers/i2c/chips/tsl2563.c
+ * tsl2563.c - TSL2563 Ambient Light Sensor
*
* Copyright (C) 2008 Nokia Corporation
*
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 0aed293..d1ad80b 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -209,16 +209,6 @@ config SENSORS_TSL2550
This driver can also be built as a module. If so, the module
will be called tsl2550.
-config SENSORS_TSL2563
- tristate "Taos TSL2563 ambient light sensor"
- depends on I2C && HWMON
- help
- If you say yes here you get support for the Taos TSL2563
- ambient light sensor.
-
- This driver can also be built as a module. If so, the module
- will be called tsl2563.
-
config MENELAUS
bool "TWL92330/Menelaus PM chip"
depends on I2C=y && ARCH_OMAP24XX
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 5e17df3..919013c 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_SENSORS_TLV320AIC23) += tlv320aic23.o
obj-$(CONFIG_GPIOEXPANDER_OMAP)+= gpio_expander_omap.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_SENSORS_TSL2550) += tsl2550.o
-obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
obj-$(CONFIG_TWL4030_CORE) += twl4030-pwrirq.o twl4030-power.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL4030_POWEROFF) += twl4030-poweroff.o
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] lp5521: move to drivers/leds
This driver should be sitting together with the other
led drivers.
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig |7 ---
drivers/i2c/chips/Makefile |1 -
drivers/leds/Kconfig |7 +++
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} |0
5 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (100%)
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index d803c41..0aed293 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -219,13 +219,6 @@ config SENSORS_TSL2563
This driver can also be built as a module. If so, the module
will be called tsl2563.
-config LP5521
- tristate "LP5521 LED driver chip"
- depends on I2C
- help
- If you say yes here you get support for the National Semiconductor
- LP5521 LED driver.
-
config MENELAUS
bool "TWL92330/Menelaus PM chip"
depends on I2C=y && ARCH_OMAP24XX
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index ba41a57..5e17df3 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -30,7 +30,6 @@ obj-$(CONFIG_TWL4030_POWEROFF)+= twl4030-poweroff.o
obj-$(CONFIG_TWL4030_PWRBUTTON)+= twl4030-pwrbutton.o
obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
obj-$(CONFIG_RTC_X1205_I2C)+= x1205.o
-obj-$(CONFIG_LP5521) += lp5521.o
ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 6a2f441..d61cdf0 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -146,6 +146,13 @@ config LEDS_CM_X270
help
This option enables support for the CM-X270 LEDs.
+config LEDS_LP5521
+ tristate "LP5521 LED driver chip"
+ depends on LEDS_CLASS && I2C
+ help
+ If you say yes here you get support for the National Semiconductor
+ LP5521 LED driver used in n8x0 boards.
+
config LEDS_CLEVO_MAIL
tristate "Mail LED on Clevo notebook (EXPERIMENTAL)"
depends on LEDS_CLASS && X86 && SERIO_I8042 && DMI && EXPERIMENTAL
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index fd6316e..ce5c8cd 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
+obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
obj-$(CONFIG_LEDS_FSG) += leds-fsg.o
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/leds/leds-lp5521.c
similarity index 100%
rename from drivers/i2c/chips/lp5521.c
rename to drivers/leds/leds-lp5521.c
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] i2c: lp5521: cosmetic fixes
General cleanup to the code. Preparing to send it to
mainline.
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/i2c/chips/lp5521.c | 159
1 files changed, 73 insertions(+), 86 deletions(-)
diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c
index 7fb8091..e040c4d 100644
--- a/drivers/i2c/chips/lp5521.c
+++ b/drivers/i2c/chips/lp5521.c
@@ -1,5 +1,5 @@
/*
- * drivers/i2c/chips/lp5521.c
+ * lp5521.c - LP5521 LED Driver
*
* Copyright (C) 2007 Nokia Corporation
*
@@ -24,7 +24,6 @@
#include
#include
#include
-#include
#define LP5521_DRIVER_NAME "lp5521"
@@ -71,6 +70,7 @@
#define LP5521_PROGRAM_LENGTH 32 /* in bytes */
struct lp5521_chip {
+ /* device lock */
struct mutexlock;
struct i2c_client *client;
char*mode;
@@ -81,20 +81,14 @@ struct lp5521_chip {
static int lp5521_set_mode(struct lp5521_chip *chip, char *mode);
-static int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
+static inline int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
{
return i2c_smbus_write_byte_data(client, reg, value);
}
-static int lp5521_read(struct i2c_client *client, u8 reg, u8 *buf)
+static inline int lp5521_read(struct i2c_client *client, u8 reg)
{
- s32 ret = i2c_smbus_read_byte_data(client, reg);
-
- if (ret < 0)
- return -EIO;
-
- *buf = ret;
- return 0;
+ return i2c_smbus_read_byte_data(client, reg);
}
static int lp5521_configure(struct i2c_client *client)
@@ -136,19 +130,19 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
if (chip->red)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_R_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_R_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip->green)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_G_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_G_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
if (chip->blue)
ret |= i2c_smbus_write_i2c_block_data(client,
- LP5521_REG_B_PROG_MEM,
- LP5521_PROGRAM_LENGTH,
- pattern);
+ LP5521_REG_B_PROG_MEM,
+ LP5521_PROGRAM_LENGTH,
+ pattern);
return ret;
}
@@ -156,31 +150,33 @@ static int lp5521_load_program(struct lp5521_chip *chip,
u8 *pattern)
static int lp5521_run_program(struct lp5521_chip *chip)
{
struct i2c_client *client = chip->client;
- int ret;
+ int reg;
u8 mask = 0xc0;
u8 exec_state = 0;
- u8 enable_reg;
- ret = lp5521_read(client, LP5521_REG_ENABLE, &enable_reg);
- if (ret)
- goto fail;
+ reg = lp5521_read(client, LP5521_REG_ENABLE);
+ if (reg < 0)
+ return reg;
- enable_reg &= mask;
+ reg &= mask;
/* set all active channels exec state to countinous run*/
- exec_state |= (chip->red << 5);
+ exec_state |= (chip->red << 5);
exec_state |= (chip->green << 3);
- exec_state |= (chip->blue << 1);
+ exec_state |= (chip->blue << 1);
- enable_reg |= exec_state;
+ reg |= exec_state;
- ret |= lp5521_write(client, LP5521_REG_ENABLE, enable_reg);
+ if (lp5521_write(client, LP5521_REG_ENABLE, reg))
+ dev_dbg(&client->dev, "failed writing to register %02x\n",
+ LP5521_REG_ENABLE);
/* set op-mode to run for active channels, disabled for others */
- ret |= lp5521_write(client, LP5521_REG_OP_MODE, exec_state);
+ if (lp5521_write(client, LP5521_REG_OP_MODE, exec_state))
+ dev_dbg(&client->dev, "failed writing to register %02x\n",
+ LP5521_REG_OP_MODE);
-fail:
- return ret;
+ return 0;
}
/*--*/
@@ -188,8 +184,8 @@ fail:
/*--*/
static ssize_t show_active_channels(struct device *dev,
- struct device_attrib
[PATCH 1/8] i2c: lp5521: remove dead code
That LED_CONNECTED_WRONG was never defined so removing. If someone needs those hooks, add back via proper platform_data instead of nasty ifdefery. Cc: Richard Purdie <[EMAIL PROTECTED]> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]> --- drivers/i2c/chips/lp5521.c | 22 -- 1 files changed, 0 insertions(+), 22 deletions(-) diff --git a/drivers/i2c/chips/lp5521.c b/drivers/i2c/chips/lp5521.c index c0862d9..7fb8091 100644 --- a/drivers/i2c/chips/lp5521.c +++ b/drivers/i2c/chips/lp5521.c @@ -28,13 +28,8 @@ #define LP5521_DRIVER_NAME "lp5521" -#ifdef LED_CONNECTED_WRONG -#define LP5521_REG_R_PWM 0x04 -#define LP5521_REG_B_PWM 0x02 -#else #define LP5521_REG_R_PWM 0x02 #define LP5521_REG_B_PWM 0x04 -#endif #define LP5521_REG_ENABLE 0x00 #define LP5521_REG_OP_MODE 0x01 #define LP5521_REG_G_PWM 0x03 @@ -200,22 +195,12 @@ static ssize_t show_active_channels(struct device *dev, char channels[4]; int pos = 0; -#ifdef LED_CONNECTED_WRONG - if (chip->blue) - pos += sprintf(channels + pos, "r"); - if (chip->green) - pos += sprintf(channels + pos, "g"); - if (chip->red) - pos += sprintf(channels + pos, "b"); - -#else if (chip->red) pos += sprintf(channels + pos, "r"); if (chip->green) pos += sprintf(channels + pos, "g"); if (chip->blue) pos += sprintf(channels + pos, "b"); -#endif channels[pos] = '\0'; @@ -232,17 +217,10 @@ static ssize_t store_active_channels(struct device *dev, chip->green = 0; chip->blue = 0; -#ifdef LED_CONNECTED_WRONG - if (strchr(buf, 'r') != NULL) - chip->blue = 1; - if (strchr(buf, 'b') != NULL) - chip->red = 1; -#else if (strchr(buf, 'r') != NULL) chip->red = 1; if (strchr(buf, 'b') != NULL) chip->blue = 1; -#endif if (strchr(buf, 'g') != NULL) chip->green = 1; -- 1.6.0.2.307.gc427 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] leds: lp5521: simplify mode setting
Avoid using string magic and use integer for comparisson
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/leds/leds-lp5521.c | 52 ---
1 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index e040c4d..9e94ff8 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -46,10 +46,6 @@
#define LP5521_REG_G_PROG_MEM 0x30
#define LP5521_REG_B_PROG_MEM 0x50
-#define LP5521_MODE_LOAD "load"
-#define LP5521_MODE_RUN"run"
-#define LP5521_MODE_DIRECT_CONTROL "direct"
-
#define LP5521_CURRENT_1m5 0x0f
#define LP5521_CURRENT_3m1 0x1f
#define LP5521_CURRENT_4m7 0x2f
@@ -69,17 +65,23 @@
#define LP5521_PROGRAM_LENGTH 32 /* in bytes */
+enum lp5521_mode {
+ LP5521_MODE_LOAD,
+ LP5521_MODE_RUN,
+ LP5521_MODE_DIRECT_CONTROL,
+};
+
struct lp5521_chip {
/* device lock */
struct mutexlock;
struct i2c_client *client;
- char*mode;
+ enum lp5521_modemode;
int red;
int green;
int blue;
};
-static int lp5521_set_mode(struct lp5521_chip *chip, char *mode);
+static int lp5521_set_mode(struct lp5521_chip *chip, enum lp5521_mode mode);
static inline int lp5521_write(struct i2c_client *client, u8 reg, u8 value)
{
@@ -313,8 +315,25 @@ static ssize_t show_mode(struct device *dev,
char *buf)
{
struct lp5521_chip *chip = dev_get_drvdata(dev);
+ char *mode;
+
+ mutex_lock(&chip->lock);
+ switch (chip->mode) {
+ case LP5521_MODE_RUN:
+ mode = "run";
+ break;
+ case LP5521_MODE_LOAD:
+ mode = "load";
+ break;
+ case LP5521_MODE_DIRECT_CONTROL:
+ mode = "direct";
+ break;
+ default:
+ mode = "undefined";
+ }
+ mutex_unlock(&chip->lock);
- return sprintf(buf, "%s\n", chip->mode);
+ return sprintf(buf, "%s\n", mode);
}
static ssize_t store_mode(struct device *dev,
@@ -442,23 +461,28 @@ static void lp5521_unregister_sysfs(struct i2c_client
*client)
/* Set chip operating mode */
/*--*/
-static int lp5521_set_mode(struct lp5521_chip *chip, char *mode)
+static int lp5521_set_mode(struct lp5521_chip *chip, enum lp5521_mode mode)
{
struct i2c_client *client = chip->client ;
int ret = 0;
/* if in that mode already do nothing, except for run */
- if (!strcmp(mode, chip->mode) && strcmp(mode, LP5521_MODE_RUN))
+ if (chip->mode == mode && mode != LP5521_MODE_RUN)
return 0;
- if (!strcmp(mode, LP5521_MODE_RUN))
+ switch (mode) {
+ case LP5521_MODE_RUN:
ret = lp5521_run_program(chip);
-
- if (!strcmp(mode, LP5521_MODE_LOAD))
+ break;
+ case LP5521_MODE_LOAD:
ret |= lp5521_write(client, LP5521_REG_OP_MODE, 0x15);
-
- if (!strcmp(mode, LP5521_MODE_DIRECT_CONTROL))
+ break;
+ case LP5521_MODE_DIRECT_CONTROL:
ret |= lp5521_write(client, LP5521_REG_OP_MODE, 0x3F);
+ break;
+ default:
+ dev_dbg(&client->dev, "unsupported mode %d\n", mode);
+ }
chip->mode = mode;
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] leds: lp5521: register separate leds
Register three separate leds for lp5521 and allow
them to be controlled separately while keeping
backwards compatibility with userspace programs
based on old implementation.
Cc: Richard Purdie <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/leds/leds-lp5521.c | 146 +++-
1 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 9e94ff8..a5c3425 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -4,6 +4,7 @@
* Copyright (C) 2007 Nokia Corporation
*
* Written by Mathias Nyman <[EMAIL PROTECTED]>
+ * Updated by Felipe Balbi <[EMAIL PROTECTED]>
*
* 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
@@ -23,7 +24,9 @@
#include
#include
#include
+#include
#include
+#include
#define LP5521_DRIVER_NAME "lp5521"
@@ -75,7 +78,17 @@ struct lp5521_chip {
/* device lock */
struct mutexlock;
struct i2c_client *client;
+
+ struct work_struct red_work;
+ struct work_struct green_work;
+ struct work_struct blue_work;
+
+ struct led_classdev ledr;
+ struct led_classdev ledg;
+ struct led_classdev ledb;
+
enum lp5521_modemode;
+
int red;
int green;
int blue;
@@ -489,6 +502,87 @@ static int lp5521_set_mode(struct lp5521_chip *chip, enum
lp5521_mode mode)
return ret;
}
+static void lp5521_red_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
red_work);
+ int ret;
+
+ ret = lp5521_configure(chip->client);
+ if (ret) {
+ dev_dbg(&chip->client->dev, "could not configure lp5521, %d\n",
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip->client, LP5521_REG_R_PWM, chip->red);
+ if (ret)
+ dev_dbg(&chip->client->dev, "could not set brightness, %d\n",
+ ret);
+}
+
+static void lp5521_red_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledr);
+
+ chip->red = value;
+ schedule_work(&chip->red_work);
+}
+
+static void lp5521_green_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
green_work);
+ int ret;
+
+ ret = lp5521_configure(chip->client);
+ if (ret) {
+ dev_dbg(&chip->client->dev, "could not configure lp5521, %d\n",
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip->client, LP5521_REG_G_PWM, chip->green);
+ if (ret)
+ dev_dbg(&chip->client->dev, "could not set brightness, %d\n",
+ ret);
+}
+
+static void lp5521_green_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledg);
+
+ chip->green = value;
+ schedule_work(&chip->green_work);
+}
+
+static void lp5521_blue_work(struct work_struct *work)
+{
+ struct lp5521_chip *chip = container_of(work, struct lp5521_chip,
blue_work);
+ int ret;
+
+ ret = lp5521_configure(chip->client);
+ if (ret) {
+ dev_dbg(&chip->client->dev, "could not configure lp5521, %d\n",
+ ret);
+ return;
+ }
+
+ ret = lp5521_write(chip->client, LP5521_REG_B_PWM, chip->blue);
+ if (ret)
+ dev_dbg(&chip->client->dev, "could not set brightness, %d\n",
+ ret);
+}
+
+static void lp5521_blue_set(struct led_classdev *led,
+ enum led_brightness value)
+{
+ struct lp5521_chip *chip = container_of(led, struct lp5521_chip, ledb);
+
+ chip->blue = value;
+ schedule_work(&chip->blue_work);
+}
+
/*--*/
/* Probe, Attach, Remove */
/*--*/
@@ -509,6 +603,10 @@ static int __init lp5521_probe(struct i2c_client *client,
mutex_init(&chip->lock);
+ INIT_WORK(&chip->red_work, lp5521_red_work);
+ INIT_WORK(&chip->green_work, lp5521_green_work);
+ INIT_WORK(&chip->blue_work, lp5521_blue_work);
+
ret = lp5521_configure(client);
if (ret < 0) {
dev_err(&client->dev, "lp5521 error configuring chip \n");
@@ -521,14 +619,52 @@ static int __init lp5521_probe(struct i2c_client *client,
chip->green = 1;
chip->blue = 1;
+
[PATCH 8/8] input: tsc2005: move to gpiolib
get rid of omap-specific gpio calls and switch over
to gpiolib.
Cc: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
---
drivers/input/touchscreen/tsc2005.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/input/touchscreen/tsc2005.c
b/drivers/input/touchscreen/tsc2005.c
index 7fb107e..c9f8f5c 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -534,16 +534,14 @@ static int __devinit tsc2005_ts_init(struct tsc2005 *ts,
ts->dav_gpio = dav_gpio;
dev_dbg(&ts->spi->dev, "TSC2005: DAV GPIO = %d\n", dav_gpio);
-#ifdef CONFIG_ARCH_OMAP
- r = omap_request_gpio(dav_gpio);
+ r = gpio_request(dav_gpio, "dav_gpio");
if (r < 0) {
dev_err(&ts->spi->dev, "unable to get DAV GPIO");
goto err1;
}
- omap_set_gpio_direction(dav_gpio, 1);
+ gpio_direction_input(dav_gpio);
ts->irq = OMAP_GPIO_IRQ(dav_gpio);
dev_dbg(&ts->spi->dev, "TSC2005: DAV IRQ = %d\n", ts->irq);
-#endif
init_timer(&ts->penup_timer);
setup_timer(&ts->penup_timer, tsc2005_ts_penup_timer_handler,
(unsigned long)ts);
@@ -612,9 +610,7 @@ err3:
tsc2005_stop_scan(ts);
input_free_device(idev);
err2:
-#ifdef CONFIG_ARCH_OMAP
- omap_free_gpio(dav_gpio);
-#endif
+ gpio_free(dav_gpio);
err1:
return r;
}
@@ -671,10 +667,7 @@ static int __devexit tsc2005_remove(struct spi_device *spi)
free_irq(ts->irq, ts);
input_unregister_device(ts->idev);
-
-#ifdef CONFIG_ARCH_OMAP
- omap_free_gpio(ts->dav_gpio);
-#endif
+ gpio_free(ts->dav_gpio);
kfree(ts);
return 0;
--
1.6.0.2.307.gc427
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] updtes to few nokia drivers
The following patches updates a few nokia drivers. These
4 drivers are ready to go upstream and a patch will be
made as soon as they get applied to linux-omap.
Felipe Balbi (8):
i2c: lp5521: remove dead code
i2c: lp5521: cosmetic fixes
lp5521: move to drivers/leds
leds: lp5521: simplify mode setting
leds: lp5521: register separate leds
tsl2563: move tsl2563 to drivers/hwmon
input: lm8323: get rid of global pdata pointer
input: tsc2005: move to gpiolib
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile |1 +
drivers/{i2c/chips => hwmon}/tsl2563.c |2 +-
drivers/i2c/chips/Kconfig | 17 -
drivers/i2c/chips/Makefile |2 -
drivers/input/keyboard/lm8323.c|4 +-
drivers/input/touchscreen/tsc2005.c| 15 +-
drivers/leds/Kconfig |7 +
drivers/leds/Makefile |1 +
drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} | 379 +---
10 files changed, 280 insertions(+), 158 deletions(-)
rename drivers/{i2c/chips => hwmon}/tsl2563.c (99%)
rename drivers/{i2c/chips/lp5521.c => leds/leds-lp5521.c} (62%)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
> On Tue, 14 Oct 2008 14:21:50 +0530 "Madhusudhan Chikkature" <[EMAIL
> PROTECTED]> wrote:
>
> - Original Message -
> From: "Andrew Morton" <[EMAIL PROTECTED]>
> To: "Madhusudhan Chikkature" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
>
> Sent: Monday, October 13, 2008 9:23 PM
> Subject: Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
>
>
> >> On Mon, 13 Oct 2008 18:55:43 +0530 "Madhusudhan Chikkature" <[EMAIL
> >> PROTECTED]> wrote:
> >>
> >> - Original Message -
> >> From: "Andrew Morton" <[EMAIL PROTECTED]>
> >> To: "Gadiyar, Anand" <[EMAIL PROTECTED]>
> >> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> >> ; <[EMAIL PROTECTED]>
> >> Sent: Saturday, October 11, 2008 2:08 AM
> >> Subject: Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
> >>
> >>
> >> >> + /* set the GO bit */
> >> >> + hdq_reg_merge(hdq_data, OMAP_HDQ_CTRL_STATUS,
> >> >> OMAP_HDQ_CTRL_STATUS_GO,
> >> >> + OMAP_HDQ_CTRL_STATUS_DIR | OMAP_HDQ_CTRL_STATUS_GO);
> >> >> + /* wait for the TXCOMPLETE bit */
> >> >> + ret = wait_event_interruptible_timeout(hdq_wait_queue,
> >> >> + hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
> >> >> + if (ret < 0) {
> >> >> + dev_dbg(hdq_data->dev, "wait interrupted");
> >> >> + return -EINTR;
> >> >> + }
> >> >
> >> > Is this desirable? The user hits ^C and the driver bails out?
> >> >
> >> > I assume so, but was this tested?
> >>
> >> Andrew, What is the test scenario you mean here? A user hitting ^C when
> >> the driver is waiting for the TXCOMPLETE bit?
> >
> > Yes.
> >
>
> Yes. It is desired to return an error if the condition in the wait is not
> met. I need to change the check for return value to check for zero and neg
> value.
>
> I spent some time to test this perticular scenario.I could not really see any
> impact of hitting ^C when an application is
> transfering data in the background. When the h/w is programmed to transfer
> data and the driver issues a wait, I see that
> TXCOMPLETE interrupt comes immediately and wakes up as expected.
>
> So guess I am unable to hit ^C exactly when the driver is waiting in
> wait_event_interruptible_timeout(before the condition
> is met) for it to catch the signal. Is it generally suggested to use
> wait_event_timeout so that ^C signal is not caught?
>
I think it's reasonable to permit the driver's operations to be interrupted
in this manner. It's done in quite a few other places. But the problem is
actually *testing* it.
I guess one could do a whitebox-style test. Add new code like:
{
static int x;
if (!(x++ % 1000)) {
printk("hit ^c now\n");
msleep(2000);
}
}
in the right place.
Tricky.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP2/3 I2C: reprogram OCP_SYSCONFIG register after reset
The I2C controller clears its OCP_SYSCONFIG register after an OCP soft reset.
Reprogram OCP_SYSCONFIG for maximum power savings on rev3.6 controllers
and beyond. On 2430, this involves setting the module AUTOIDLE bit.
On 3430, this includes module AUTOIDLE, wakeup enable, slave smart-idle,
and considers only the module functional clock state for idle-ack.
Boot-tested on 2430SDP and 3430SDP.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
Cc: Richard Woodruff <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 40 ++--
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 12bdb69..d012ad7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -123,11 +123,19 @@
#define OMAP_I2C_SYSTEST_SDA_O (1 << 0)/* SDA line drive out */
#endif
-/* I2C System Status register (OMAP_I2C_SYSS): */
-#define OMAP_I2C_SYSS_RDONE(1 << 0)/* Reset Done */
+/* OCP_SYSSTATUS bit definitions */
+#define SYSS_RESETDONE_MASK(1 << 0)
+
+/* OCP_SYSCONFIG bit definitions */
+#define SYSC_CLOCKACTIVITY_MASK(0x3 << 8)
+#define SYSC_SIDLEMODE_MASK(0x3 << 3)
+#define SYSC_ENAWAKEUP_MASK(1 << 2)
+#define SYSC_SOFTRESET_MASK(1 << 1)
+#define SYSC_AUTOIDLE_MASK (1 << 0)
+
+#define SYSC_IDLEMODE_SMART0x2
+#define SYSC_CLOCKACTIVITY_FCLK0x2
-/* I2C System Configuration Register (OMAP_I2C_SYSC): */
-#define OMAP_I2C_SYSC_SRST (1 << 1)/* Soft Reset */
struct omap_i2c_dev {
struct device *dev;
@@ -252,13 +260,13 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long internal_clk = 0;
if (dev->rev >= OMAP_I2C_REV_2) {
- omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, SYSC_SOFTRESET_MASK);
/* For some reason we need to set the EN bit before the
* reset done bit gets set. */
timeout = jiffies + OMAP_I2C_TIMEOUT;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
while (!(omap_i2c_read_reg(dev, OMAP_I2C_SYSS_REG) &
-OMAP_I2C_SYSS_RDONE)) {
+SYSS_RESETDONE_MASK)) {
if (time_after(jiffies, timeout)) {
dev_warn(dev->dev, "timeout waiting "
"for controller reset\n");
@@ -266,6 +274,26 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
}
msleep(1);
}
+
+ /* SYSC register is cleared by the reset; rewrite it */
+ if (dev->rev == OMAP_I2C_REV_ON_2430) {
+
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
+ SYSC_AUTOIDLE_MASK);
+
+ } else if (dev->rev >= OMAP_I2C_REV_ON_3430) {
+ u32 v;
+
+ v = SYSC_AUTOIDLE_MASK;
+ v |= SYSC_ENAWAKEUP_MASK;
+ v |= (SYSC_IDLEMODE_SMART <<
+ __ffs(SYSC_SIDLEMODE_MASK));
+ v |= (SYSC_CLOCKACTIVITY_FCLK <<
+ __ffs(SYSC_CLOCKACTIVITY_MASK));
+
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
+
+ }
}
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP: I2C: convert 'rev1' flag to generic 'rev' u8
i2c-omap discriminates only between "revision 1" or "greater than
revision 1." A following patch introduces code that must also
discriminate between rev2.x, rev3.6, and rev3.12 controllers. Support
this by storing the full revision data from the I2C_REV register, rather
than just a single bit.
The revision definitions may need to be extended for other ES levels
that aren't currently available here. rev3.6 is what's present on the
2430SDP here (unknown ES revision); rev3.12 is used on the 3430ES2
here.
Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
---
drivers/i2c/busses/i2c-omap.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a999606..12bdb69 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -38,6 +38,13 @@
#include
#include
+/* I2C controller revisions */
+#define OMAP_I2C_REV_2 0x20
+
+/* I2C controller revisions present on specific hardware */
+#define OMAP_I2C_REV_ON_2430 0x36
+#define OMAP_I2C_REV_ON_3430 0x3C
+
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -139,7 +146,7 @@ struct omap_i2c_dev {
* fifo_size==0 implies no fifo
* if set, should be trsh+1
*/
- unsignedrev1:1;
+ u8 rev;
unsignedb_hw:1; /* bad h/w fixes */
unsignedidle:1;
u16 iestate;/* Saved interrupt register */
@@ -220,7 +227,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
- if (dev->rev1)
+ if (dev->rev < OMAP_I2C_REV_2)
iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
else
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
@@ -244,7 +251,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
unsigned long timeout;
unsigned long internal_clk = 0;
- if (!dev->rev1) {
+ if (dev->rev >= OMAP_I2C_REV_2) {
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
/* For some reason we need to set the EN bit before the
* reset done bit gets set. */
@@ -718,6 +725,7 @@ omap_i2c_probe(struct platform_device *pdev)
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
struct resource *mem, *irq, *ioarea;
+ void *isr;
int r;
u32 *speed = NULL;
@@ -769,8 +777,7 @@ omap_i2c_probe(struct platform_device *pdev)
omap_i2c_unidle(dev);
- if (cpu_is_omap15xx())
- dev->rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) < 0x20;
+ dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
if (cpu_is_omap2430() || cpu_is_omap34xx()) {
u16 s;
@@ -791,16 +798,16 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- r = request_irq(dev->irq, dev->rev1 ? omap_i2c_rev1_isr : omap_i2c_isr,
- 0, pdev->name, dev);
+ isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
+ r = request_irq(dev->irq, isr, 0, pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
goto err_unuse_clocks;
}
- r = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
+
dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n",
-pdev->id, r >> 4, r & 0xf, dev->speed);
+pdev->id, dev->rev >> 4, dev->rev & 0xf, dev->speed);
omap_i2c_idle(dev);
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP: I2C: reprogram OCP_SYSCONFIG after device reset
Hello, This patch set programs the I2C controller OCP_SYSCONFIG register after the driver resets the device. It is derived from the changes mentioned by Richard Woodruff <[EMAIL PROTECTED]> at http://git.omapzoom.org/?p=omapkernel;a=blob;f=drivers/i2c/busses/i2c-omap.c;hb=d0b4bad4926f9a147a73498f7a62a0ae1cf6f83a however, the CLOCKACTIVITY change on clk_enable()/clk_disable() in that code currently seems pointless, so it has been excluded until more information is available from TI or until problems are encountered. This patchset should only change behavior on OMAP2x30 and OMAP3xxx devices. Boot-tested on 2430SDP and 3430SDP; compile-tested with the 5912OSK (OMAP1) defconfig. Comments welcome, - Paul --- textdata bss dec hex filename 3472584 160600 105760 3738944 390d40 vmlinux.3430sdp.orig 3472616 160600 105760 3738976 390d60 vmlinux.3430sdp drivers/i2c/busses/i2c-omap.c | 65 - 1 files changed, 50 insertions(+), 15 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/05] OMAP3: CPUidle driver
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Hilman > Sent: Thursday, October 09, 2008 8:15 PM > To: Rajendra Nayak > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 00/05] OMAP3: CPUidle driver > > Kevin Hilman <[EMAIL PROTECTED]> writes: > > > "Rajendra Nayak" <[EMAIL PROTECTED]> writes: > > > >> This patch set implements Cpuidle driver for OMAP3 platforms. It is > >> validated on the 3430SDP (using the omap_3430sdp_min_defconfig) and > >> applies on the pm-20081006 branch. > > > > Excellent. Thank you. I'll pull into pm-20081006 today. > > > > One question: You have C6 to hit chip-off, but it is never enabled. > > Has this been tested? Enabling it allows me to hit chip OFF, but it > > never comes back from OFF-mode. I will push some patches > to make this > > work with /sys/power/enable_off_mode. > > I got this to work on custom HW, but not on 3430SDP. Can you confirm > whether or not you can use C6 on 3430SDP? Off-in-idle without CPUidle > seems to work, but not with CPUidle + C6. > > Hi Kevin, With just this patch below I could see that I was able to hit sysoff even with CPUidle. Doing this I could see the SYSOFF LED toggle.. # echo -n 1 > /sys/power/clocks_off_while_idle # echo -n 1 > /sys/power/sleep_while_idle # echo -n 1 > /sys/power/voltage_off_while_idle # echo -n 1 > /sys/power/enable_off_mode And doing this stops the toggle.. # echo -n 0 > /sys/power/enable_off_mode Was there any other issue you saw with CPUidle + C6? Rajendra --- arch/arm/mach-omap2/cpuidle34xx.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c === --- linux-omap-2.6.orig/arch/arm/mach-omap2/cpuidle34xx.c 2008-10-14 14:46:21.0 +0530 +++ linux-omap-2.6/arch/arm/mach-omap2/cpuidle34xx.c2008-10-14 14:46:24.0 +0530 @@ -191,7 +191,7 @@ void omap_init_power_states(void) CPUIDLE_FLAG_CHECK_BM; /* C6 . MPU OFF + Core OFF */ - omap3_power_states[OMAP3_STATE_C6].valid = 0; + omap3_power_states[OMAP3_STATE_C6].valid = 1; omap3_power_states[OMAP3_STATE_C6].type = OMAP3_STATE_C6; omap3_power_states[OMAP3_STATE_C6].sleep_latency = 1; omap3_power_states[OMAP3_STATE_C6].wakeup_latency = 3; > > > Some minor problems that I will fixup when rebasing to the next pm > > branch: > > > > - You removed C0, but all the comments still refer to it > > - /sys/power/enable_off_mode doesn't affect off-mode states > >in CPUidle > > > > patch 1: > > - I still don't like the #ifdefs for the init sequence. > > > > patch 2: > > - checkpatch warning > > > > Kevin > > > >> The following C states are defined and used > >> > >> * C0 . System executing code (Not an idle state) > >> * C1 . MPU WFI + Core active > >> * C2 . MPU CSWR + Core active > >> * C3 . MPU OFF + Core active > >> * C4 . MPU CSWR + Core CSWR > >> * C5 . MPU OFF + Core CSWR > >> * C6 . MPU OFF + Core OFF > >> > >> CPUidle support is not enabled by default in any of the > defconfigs and hence has to enabled seperately > >> if you plan to test these patches. > >> > >> CPUIdle ---> [*] CPU idle PM support > >> > >> regards, > >> Rajendra > -- > To unsubscribe from this list: send the line "unsubscribe > linux-omap" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] Errata: ES3.0 SDRC not sending auto-refresh when OMAP wakes-up from OFF mode
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm34xx.c |5 ++-
arch/arm/mach-omap2/sleep34xx.S | 84 +-
arch/arm/plat-omap/include/mach/pm.h |1 +
3 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 513c4bf..5474b12 100755
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -982,7 +982,10 @@ void save_scratchpad_contents(void)
/* Get virtual address of SCRATCHPAD */
scratchpad_address = (u32 *) OMAP2_IO_ADDRESS(SCRATCHPAD);
/* Get Restore pointer to jump to while waking up from OFF */
- restore_address = get_restore_pointer();
+ if (system_rev >= OMAP3430_REV_ES3_0)
+ restore_address = get_es3_restore_pointer();
+ else
+ restore_address = get_restore_pointer();
/* Convert it to physical address */
restore_address = (u32 *) io_v2p(restore_address);
/* Get address where registers are saved in SDRAM */
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index a2bdab2..f724e65 100755
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -35,6 +35,7 @@
#define PM_PREPWSTST_CORE_VOMAP34XX_PRM_REGADDR(CORE_MOD, \
OMAP3430_PM_PREPWSTST)
+#define PM_PREPWSTST_CORE_P0x48306AE8
#define PM_PREPWSTST_MPU_V OMAP34XX_PRM_REGADDR(MPU_MOD, \
OMAP3430_PM_PREPWSTST)
#define PM_PWSTCTRL_MPU_P 0x483069E0
@@ -44,6 +45,13 @@
* available */
#define SCRATCHPAD_BASE_P 0x48002910
#define SDRC_POWER_V OMAP34XX_SDRC_REGADDR(SDRC_POWER)
+#define SDRC_SYSCONFIG_P (OMAP343X_SDRC_BASE + SDRC_SYSCONFIG)
+#define SDRC_MR_0_P(OMAP343X_SDRC_BASE + SDRC_MR_0)
+#define SDRC_EMR2_0_P (OMAP343X_SDRC_BASE + SDRC_EMR2_0)
+#define SDRC_MANUAL_0_P(OMAP343X_SDRC_BASE + SDRC_MANUAL_0)
+#define SDRC_MR_1_P(OMAP343X_SDRC_BASE + SDRC_MR_1)
+#define SDRC_EMR2_1_P (OMAP343X_SDRC_BASE + SDRC_EMR2_1)
+#define SDRC_MANUAL_1_P(OMAP343X_SDRC_BASE + SDRC_MANUAL_1)
.text
/* Function call to get the restore pointer for resume from OFF */
@@ -52,7 +60,59 @@ ENTRY(get_restore_pointer)
adr r0, restore
ldmfd sp!, {pc} @ restore regs and return
ENTRY(get_restore_pointer_sz)
-.word . - get_restore_pointer_sz
+.word . - get_restore_pointer
+
+ .text
+/* Function call to get the restore pointer for for ES3 to resume from OFF */
+ENTRY(get_es3_restore_pointer)
+stmfd sp!, {lr} @ save registers on stack
+ adr r0, restore_es3
+ldmfd sp!, {pc} @ restore regs and return
+ENTRY(get_es3_restore_pointer_sz)
+.word . - get_es3_restore_pointer
+
+ENTRY(es3_sdrc_fix)
+ ldr r4, sdrc_syscfg @ get config addr
+ ldr r5, [r4]@ get value
+ tst r5, #0x100 @ is part access blocked
+ it eq
+ biceq r5, r5, #0x100 @ clear bit if set
+ str r5, [r4]@ write back change
+ ldr r4, sdrc_mr_0 @ get config addr
+ ldr r5, [r4]@ get value
+ str r5, [r4]@ write back change
+ ldr r4, sdrc_emr2_0 @ get config addr
+ ldr r5, [r4]@ get value
+ str r5, [r4]@ write back change
+ ldr r4, sdrc_manual_0 @ get config addr
+ mov r5, #0x2@ autorefresh command
+ str r5, [r4]@ kick off refreshes
+ ldr r4, sdrc_mr_1 @ get config addr
+ ldr r5, [r4]@ get value
+ str r5, [r4]@ write back change
+ ldr r4, sdrc_emr2_1 @ get config addr
+ ldr r5, [r4]@ get value
+ str r5, [r4]@ write back change
+ ldr r4, sdrc_manual_1 @ get config addr
+ mov r5, #0x2@ autorefresh command
+ str r5, [r4]@ kick off refreshes
+ bx lr
+sdrc_syscfg:
+ .word SDRC_SYSCONFIG_P
+sdrc_mr_0:
+ .word SDRC_MR_0_P
+sdrc_emr2_0:
+ .word SDRC_EMR2_0_P
+sdrc_manual_0:
+ .word SDRC_MANUAL_0_P
+sdrc_mr_1:
+ .word SDRC_MR_1_P
+sdrc_emr2_1:
+ .word SDRC_EMR2_1_P
+sdrc_manual_1:
+ .word SDRC_MANUAL_1_P
+ENTRY(es3_sdrc_fix_sz)
+ .word . - es3_sdrc_fix
/* Function to call rom code to save secure ram context */
ENTRY(save_secure_ram_context)
@@ -130,6 +190,24 @@ loop:
bl i_dll_wait
ldmfd sp!, {r0-r12, pc} @ restore regs and return
+restore_es3:
+ /*b restore_es3*/ @ Enab
[PATCH 1/6] Support for EMU/HS off-mode for DMA
- DMA interrupt disable routine added
- Added DMA controller reset to DMA context restore
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/dma.c | 14 ++
arch/arm/plat-omap/include/mach/dma.h |2 ++
2 files changed, 16 insertions(+), 0 deletions(-)
mode change 100644 => 100755 arch/arm/plat-omap/dma.c
mode change 100644 => 100755 arch/arm/plat-omap/include/mach/dma.h
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
old mode 100644
new mode 100755
index 38c57ce..4d4016f
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2309,6 +2309,9 @@ EXPORT_SYMBOL(omap_dma_global_context_save);
void omap_dma_global_context_restore(void)
{
+ dma_write(0x2, OCP_SYSCONFIG);
+ while (!__raw_readl(omap_dma_base + OMAP_DMA4_SYSSTATUS))
+ ;
dma_write(omap_dma_global_context.dma_gcr, GCR);
dma_write(omap_dma_global_context.dma_ocp_sysconfig,
OCP_SYSCONFIG);
@@ -2317,6 +2320,17 @@ void omap_dma_global_context_restore(void)
}
EXPORT_SYMBOL(omap_dma_global_context_restore);
+void omap_dma_disable_irq(int lch)
+{
+ u32 val;
+ if (cpu_class_is_omap2()) {
+ /* Disable interrupts */
+ val = dma_read(IRQENABLE_L0);
+ val &= ~(1 << lch);
+ dma_write(val, IRQENABLE_L0);
+ }
+}
+
/**/
static int __init omap_init_dma(void)
diff --git a/arch/arm/plat-omap/include/mach/dma.h
b/arch/arm/plat-omap/include/mach/dma.h
old mode 100644
new mode 100755
index f1f588a..1cd390d
--- a/arch/arm/plat-omap/include/mach/dma.h
+++ b/arch/arm/plat-omap/include/mach/dma.h
@@ -531,6 +531,8 @@ extern int omap_get_dma_index(int lch, int *ei, int *fi);
void omap_dma_global_context_save(void);
void omap_dma_global_context_restore(void);
+extern void omap_dma_disable_irq(int lch);
+
/* Chaining APIs */
#ifndef CONFIG_ARCH_OMAP1
extern int omap_request_dma_chain(int dev_id, const char *dev_name,
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] Add new register definitions for SDRAM controller
Added SDRC_EMR2_* and SDRC_MANUAL_* Signed-off-by: Tero Kristo <[EMAIL PROTECTED]> --- arch/arm/plat-omap/include/mach/sdrc.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-omap/include/mach/sdrc.h b/arch/arm/plat-omap/include/mach/sdrc.h index c66c838..a5a6cf9 100644 --- a/arch/arm/plat-omap/include/mach/sdrc.h +++ b/arch/arm/plat-omap/include/mach/sdrc.h @@ -31,14 +31,18 @@ #define SDRC_POWER 0x070 #define SDRC_MCFG_00x080 #define SDRC_MR_0 0x084 +#define SDRC_EMR2_00x08c #define SDRC_ACTIM_CTRL_A_00x09c #define SDRC_ACTIM_CTRL_B_00x0a0 #define SDRC_RFR_CTRL_00x0a4 +#define SDRC_MANUAL_0 0x0a8 #define SDRC_MCFG_10x0B0 #define SDRC_MR_1 0x0B4 +#define SDRC_EMR2_10x0BC #define SDRC_ACTIM_CTRL_A_10x0C4 #define SDRC_ACTIM_CTRL_B_10x0C8 #define SDRC_RFR_CTRL_10x0D4 +#define SDRC_MANUAL_1 0x0D8 /* * These values represent the number of memory clock cycles between -- 1.5.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PM: OMAP3 HS/EMU off-mode support
This patchset provides off-mode support for OMAP3 HS/EMU devices. Due to secure environment in these devices, wake-up from off-mode is slightly different than in GP devices. This code has been tested on following chip versions: ES2.1GP, ES3.0EMU, ES3.0HS. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] HS/EMU OMAP3 SRAM size fix
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/plat-omap/sram.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
mode change 100644 => 100755 arch/arm/plat-omap/sram.c
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
old mode 100644
new mode 100755
index 9cfb77f..f0ac426
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -125,9 +125,15 @@ void __init omap_detect_sram(void)
if (cpu_class_is_omap2()) {
if (is_sram_locked()) {
if (cpu_is_omap34xx()) {
- omap_sram_base = OMAP3_SRAM_PUB_VA;
- omap_sram_start = OMAP3_SRAM_PUB_PA;
- omap_sram_size = 0x8000; /* 32K */
+ if (omap_type() == OMAP2_DEVICE_TYPE_GP) {
+ omap_sram_base = OMAP3_SRAM_PUB_VA;
+ omap_sram_start = OMAP3_SRAM_PUB_PA;
+ omap_sram_size = 0x8000; /* 32K */
+ } else {
+ omap_sram_base = OMAP3_SRAM_PUB_VA;
+ omap_sram_start = OMAP3_SRAM_PUB_PA;
+ omap_sram_size = 0x7000; /* 28K */
+ }
} else {
omap_sram_base = OMAP2_SRAM_PUB_VA;
omap_sram_start = OMAP2_SRAM_PUB_PA;
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] Enable SDRAM auto-refresh during sleep
Fix for ES3.0 bug: SDRC not sending auto-refresh when OMAP wakes-up from OFF
mode (warning for HS devices.)
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm34xx.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index d5892c5..513c4bf 100755
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -46,6 +46,11 @@
#define OMAP3430_PRM_RSTST \
OMAP34XX_PRM_REGADDR(OMAP3430_GR_MOD, 0x0058)
+#define SDRC_POWER_AUTOCOUNT_SHIFT 8
+#define SDRC_POWER_AUTOCOUNT_MASK (0x << SDRC_POWER_AUTOCOUNT_SHIFT)
+#define SDRC_POWER_CLKCTRL_SHIFT 4
+#define SDRC_POWER_CLKCTRL_MASK (0x3 << SDRC_POWER_CLKCTRL_SHIFT)
+#define SDRC_SELF_REFRESH_ON_AUTOCOUNT (0x2 << SDRC_POWER_CLKCTRL_SHIFT)
u32 context_mem[128];
@@ -349,12 +354,34 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
}
+ /*
+* Force SDRAM controller to self-refresh mode after timeout on
+* autocount. This is needed on ES3.0 to avoid SDRAM controller
+* hang-ups.
+*/
+ if (system_rev >= OMAP3430_REV_ES3_0 &&
+ omap_type() != OMAP2_DEVICE_TYPE_GP &&
+ core_next_state == PWRDM_POWER_OFF) {
+ sdrc_pwr = sdrc_read_reg(SDRC_POWER);
+ sdrc_write_reg((sdrc_pwr &
+ ~(SDRC_POWER_AUTOCOUNT_MASK|SDRC_POWER_CLKCTRL_MASK)) |
+ (1 << SDRC_POWER_AUTOCOUNT_SHIFT) |
+ SDRC_SELF_REFRESH_ON_AUTOCOUNT, SDRC_POWER);
+ }
+
*(scratchpad_restore_addr) = restore_pointer_address;
_omap_sram_idle(context_mem, save_state);
*(scratchpad_restore_addr) = 0x0;
+ /* Restore normal SDRAM settings */
+ if (system_rev >= OMAP3430_REV_ES3_0 &&
+ omap_type() != OMAP2_DEVICE_TYPE_GP &&
+ core_next_state == PWRDM_POWER_OFF) {
+ sdrc_write_reg(sdrc_pwr, SDRC_POWER);
+ }
+
/* Restore table entry modified during MMU restoration */
if (pwrdm_read_prev_pwrst(mpu_pwrdm) == 0x0)
restore_table_entry();
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] PM: OMAP3 HS/EMU off-mode support
Signed-off-by: Tero Kristo <[EMAIL PROTECTED]>
---
arch/arm/mach-omap2/pm34xx.c | 58 +-
arch/arm/mach-omap2/sleep34xx.S | 74 ++
arch/arm/plat-omap/include/mach/pm.h |2 +
3 files changed, 132 insertions(+), 2 deletions(-)
mode change 100644 => 100755 arch/arm/mach-omap2/pm34xx.c
mode change 100644 => 100755 arch/arm/mach-omap2/sleep34xx.S
mode change 100644 => 100755 arch/arm/plat-omap/include/mach/pm.h
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
old mode 100644
new mode 100755
index 9d97dd6..d5892c5
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include "sdrc.h"
@@ -55,6 +56,11 @@ struct power_state {
struct list_head node;
};
+struct sram_mem {
+ u32 i[32000];
+};
+struct sram_mem *sdram_mem;
+
u32 *scratchpad_restore_addr;
u32 restore_pointer_address;
@@ -62,6 +68,8 @@ static LIST_HEAD(pwrst_list);
void (*_omap_sram_idle)(u32 *addr, int save_state);
+static int (*_omap_save_secure_sram)(u32 *addr);
+
static void (*saved_idle)(void);
static struct powerdomain *mpu_pwrdm;
@@ -208,6 +216,32 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
return IRQ_HANDLED;
}
+void omap3_save_secure_ram_context(u32 target_mpu_state)
+{
+ u32 ret;
+
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+ /* Disable dma irq before calling secure rom code API */
+ omap_dma_disable_irq(0);
+ omap_dma_disable_irq(1);
+ /*
+* MPU next state must be set to POWER_ON temporarily,
+* otherwise the WFI executed inside the ROM code
+* will hang the system.
+*/
+ pwrdm_set_next_pwrst(mpu_pwrdm, PWRDM_POWER_ON);
+ ret = _omap_save_secure_sram((u32 *)__pa(sdram_mem));
+ pwrdm_set_next_pwrst(mpu_pwrdm, target_mpu_state);
+ /* Following is for error tracking, it should not happen */
+ if (ret) {
+ printk(KERN_ERR "save_secure_sram() returns %08x\n",
+ ret);
+ while (1)
+ ;
+ }
+ }
+}
+
static void restore_control_register(u32 val)
{
__asm__ __volatile__ ("mcr p15, 0, %0, c1, c0, 0" : : "r" (val));
@@ -249,6 +283,7 @@ void omap_sram_idle(void)
int mpu_next_state = PWRDM_POWER_ON, core_next_state = PWRDM_POWER_ON,
per_next_state = PWRDM_POWER_ON;
int mpu_prev_state, core_prev_state, per_prev_state;
+ u32 sdrc_pwr;
if (!_omap_sram_idle)
return;
@@ -304,6 +339,7 @@ void omap_sram_idle(void)
omap3_save_core_ctx();
omap_save_uart_ctx(0);
omap_save_uart_ctx(1);
+ omap3_save_secure_ram_context(mpu_next_state);
}
omap_serial_enable_clocks(0, 0);
omap_serial_enable_clocks(0, 1);
@@ -809,6 +845,9 @@ void omap_push_sram_idle()
{
_omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
omap34xx_cpu_suspend_sz);
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP)
+ _omap_save_secure_sram = omap_sram_push(save_secure_ram_context,
+ save_secure_ram_context_sz);
}
int __init omap3_pm_init(void)
@@ -822,7 +861,6 @@ int __init omap3_pm_init(void)
/* XXX prcm_setup_regs needs to be before enabling hw
* supervised mode for powerdomains */
prcm_setup_regs();
- save_scratchpad_contents();
ret = request_irq(INT_34XX_PRCM_MPU_IRQ,
(irq_handler_t)prcm_interrupt_handler,
@@ -867,6 +905,19 @@ int __init omap3_pm_init(void)
pwrdm_add_wkdep(neon_pwrdm, mpu_pwrdm);
pwrdm_add_wkdep(per_pwrdm, core_pwrdm);
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
+ sdram_mem = kmalloc(sizeof(struct sram_mem), GFP_KERNEL);
+ if (!sdram_mem)
+ printk(KERN_ERR "Memory allocation failed when"
+ "allocating for secure sram context\n");
+ }
+ save_scratchpad_contents();
+
+ printk(KERN_INFO "system_rev=%08x\n", system_rev);
+ if (omap_type() == OMAP2_DEVICE_TYPE_GP)
+ printk(KERN_INFO "GP device\n");
+ else
+ printk(KERN_INFO "non-GP device\n");
err1:
return ret;
err2:
@@ -921,7 +972,10 @@ void save_scratchpad_contents(void)
restore_pointer_address = (u32) restore_address;
*(scratchpad_address++) = 0x0;
/* Secure ram restore pointer */
- *(scratchpad_address++) = 0x0;
+ if (omap_type() == OMAP2_DEVICE_TYPE_GP)
+ *(scratchpa
Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
- Original Message -
From: "Andrew Morton" <[EMAIL PROTECTED]>
To: "Madhusudhan Chikkature" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
Sent: Monday, October 13, 2008 9:23 PM
Subject: Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
>> On Mon, 13 Oct 2008 18:55:43 +0530 "Madhusudhan Chikkature" <[EMAIL
>> PROTECTED]> wrote:
>>
>> - Original Message -
>> From: "Andrew Morton" <[EMAIL PROTECTED]>
>> To: "Gadiyar, Anand" <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ;
>> <[EMAIL PROTECTED]>
>> Sent: Saturday, October 11, 2008 2:08 AM
>> Subject: Re: [PATCH 1/5] HDQ Driver for OMAP2430/3430
>>
>>
>> >> + /* set the GO bit */
>> >> + hdq_reg_merge(hdq_data, OMAP_HDQ_CTRL_STATUS,
>> >> OMAP_HDQ_CTRL_STATUS_GO,
>> >> + OMAP_HDQ_CTRL_STATUS_DIR | OMAP_HDQ_CTRL_STATUS_GO);
>> >> + /* wait for the TXCOMPLETE bit */
>> >> + ret = wait_event_interruptible_timeout(hdq_wait_queue,
>> >> + hdq_data->hdq_irqstatus, OMAP_HDQ_TIMEOUT);
>> >> + if (ret < 0) {
>> >> + dev_dbg(hdq_data->dev, "wait interrupted");
>> >> + return -EINTR;
>> >> + }
>> >
>> > Is this desirable? The user hits ^C and the driver bails out?
>> >
>> > I assume so, but was this tested?
>>
>> Andrew, What is the test scenario you mean here? A user hitting ^C when the
>> driver is waiting for the TXCOMPLETE bit?
>
> Yes.
>
Yes. It is desired to return an error if the condition in the wait is not met.
I need to change the check for return value to check for zero and neg value.
I spent some time to test this perticular scenario.I could not really see any
impact of hitting ^C when an application is
transfering data in the background. When the h/w is programmed to transfer data
and the driver issues a wait, I see that
TXCOMPLETE interrupt comes immediately and wakes up as expected.
So guess I am unable to hit ^C exactly when the driver is waiting in
wait_event_interruptible_timeout(before the condition
is met) for it to catch the signal. Is it generally suggested to use
wait_event_timeout so that ^C signal is not caught?
Regards,
Madhu
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the arm tree
On Tuesday 14 October 2008, Russell King wrote: > Since the OMAP updates I merged from Tony are already broken due to > missing definitions, and I'm not getting any response from Tony on > fixing those, Probably has to do with his travel plans, which he mentioned last week (Thursday?). I think he's back online in the next day or two. > I will be dropping the problematical updates so we can > at least keep mainline OMAP in a buildable state. That seems to mean > dropping the new OMAP3 support. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the arm tree
On Tue, Oct 14, 2008 at 01:27:45PM +1100, Stephen Rothwell wrote:
> Hi Russell,
>
> Today's linux-next merge of the arm tree got a conflict in
> arch/arm/plat-omap/devices.c between commit
> 2817142f31bfbf26c216bf4f9192540c81b2d071 ("[WATCHDOG] omap_wdt.c: sync
> linux-omap changes") from Linus' tree and commit
> cc26b3b01bc96a8b8c36671b0dc4898b2a152ea8 ("ARM: OMAP3: Add minimal
> omap3430 support") from the arm tree.
>
> The former removed code that the latter modified. I fixed it up
> by just removing the section of code as the former patch seems to take
> account of what the latter is trying to do (but it may not be correct).
> You can fix it by merging Linus' tree and doing this or a similar (maybe
> correct) fixup.
This sounds very messy. I suspect I need Tony to look at that and
tell me what the right solution is. However...
Since the OMAP updates I merged from Tony are already broken due to
missing definitions, and I'm not getting any response from Tony on
fixing those, I will be dropping the problematical updates so we can
at least keep mainline OMAP in a buildable state. That seems to mean
dropping the new OMAP3 support.
That would include dropping the above commit causing the merge conflict.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
