[PATCH 0/5] [RESEND] lm8323 patches

[PATCH 0/5] [RESEND] lm8323 patches

[Felipe Balbi]

Hi Tony,

the final version is already going to mainline via linux-input,
you might wanna apply these to l-o to avoid conflicts later.

Felipe Balbi (5):
  input: lm8323: get rid of global pdata pointer
  input: lm8323: get rid of useless debug macro
  input: lm8323: general clean up
  input: lm8323: prefix led name
  input: keyboard: removed unused lm8323_set_platform_data

 arch/arm/mach-omap2/board-n800.c |   14 +++--
 drivers/input/keyboard/lm8323.c  |  113 +++++++++++++++----------------------
 include/linux/i2c/lm8323.h       |    2 -
 3 files changed, 55 insertions(+), 74 deletions(-)

[PATCH 1/5] input: lm8323: get rid of global pdata pointer

[Felipe Balbi]

From: Felipe Balbi <felipe.balbi@nokia.com>

pdata is only used during probe to initialize a few fields
from lm8323 device structure. Moving pdata pointer to probe
won't harm anybody.

Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
---
 drivers/input/keyboard/lm8323.c |   34 ++++++++++++++++------------------
 1 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 342ef6a..60abe61 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -186,9 +186,6 @@ static struct lm8323_chip *pwm_to_lm8323(struct lm8323_pwm *pwm)
 	}
 }
 
-static struct lm8323_platform_data *lm8323_pdata;
-
-
 #define LM8323_MAX_DATA 8
 
 /*
@@ -682,6 +679,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 *pdata;
 	struct input_dev *idev;
 	struct lm8323_chip *lm;
 	int i, err = 0;
@@ -694,11 +692,11 @@ static int lm8323_probe(struct i2c_client *client,
 
 	i2c_set_clientdata(client, lm);
 	lm->client = client;
-	lm8323_pdata = client->dev.platform_data;
-	if (!lm8323_pdata)
+	pdata = client->dev.platform_data;
+	if (!pdata)
 		return -EINVAL; /* ? */
 
-	lm->size_x = lm8323_pdata->size_x;
+	lm->size_x = pdata->size_x;
 	if (lm->size_x == 0) {
 		lm->size_x = 8;
 	} else if (lm->size_x > 8) {
@@ -707,7 +705,7 @@ static int lm8323_probe(struct i2c_client *client,
 		lm->size_x = 8;
 	}
 
-	lm->size_y = lm8323_pdata->size_y;
+	lm->size_y = pdata->size_y;
 	if (lm->size_y == 0) {
 		lm->size_y = 12;
 	} else if (lm->size_y > 12) {
@@ -718,13 +716,13 @@ static int lm8323_probe(struct i2c_client *client,
 
 	debug(&c->dev, "Keypad size: %d x %d\n", lm->size_x, lm->size_y);
 
-	lm->debounce_time = lm8323_pdata->debounce_time;
+	lm->debounce_time = pdata->debounce_time;
 	if (lm->debounce_time == 0) /* Default. */
 		lm->debounce_time = 12;
 	else if (lm->debounce_time == -1) /* Disable debounce. */
 		lm->debounce_time = 0;
 
-	lm->active_time = lm8323_pdata->active_time;
+	lm->active_time = pdata->active_time;
 	if (lm->active_time == 0) /* Default. */
 		lm->active_time = 500;
 	else if (lm->active_time == -1) /* Disable sleep. */
@@ -756,11 +754,11 @@ static int lm8323_probe(struct i2c_client *client,
 		goto fail2;
 	}
 
-	if (init_pwm(lm, 1, &client->dev, lm8323_pdata->pwm1_name) < 0)
+	if (init_pwm(lm, 1, &client->dev, pdata->pwm1_name) < 0)
 		goto fail3;
-	if (init_pwm(lm, 2, &client->dev, lm8323_pdata->pwm2_name) < 0)
+	if (init_pwm(lm, 2, &client->dev, pdata->pwm2_name) < 0)
 		goto fail4;
-	if (init_pwm(lm, 3, &client->dev, lm8323_pdata->pwm3_name) < 0)
+	if (init_pwm(lm, 3, &client->dev, pdata->pwm3_name) < 0)
 		goto fail5;
 
 	mutex_init(&lm->lock);
@@ -787,8 +785,8 @@ static int lm8323_probe(struct i2c_client *client,
 		goto fail8;
 	}
 
-	if (lm8323_pdata->name)
-		idev->name = lm8323_pdata->name;
+	if (pdata->name)
+		idev->name = pdata->name;
 	else
 		idev->name = "LM8323 keypad";
 	snprintf(lm->phys, sizeof(lm->phys), "%s/input-kp", client->dev.bus_id);
@@ -797,13 +795,13 @@ static int lm8323_probe(struct i2c_client *client,
 	lm->keys_down = 0;
 	idev->evbit[0] = BIT(EV_KEY);
 	for (i = 0; i < LM8323_KEYMAP_SIZE; i++) {
-		if (lm8323_pdata->keymap[i] > 0)
-			set_bit(lm8323_pdata->keymap[i], idev->keybit);
+		if (pdata->keymap[i] > 0)
+			set_bit(pdata->keymap[i], idev->keybit);
 
-		lm->keymap[i] = lm8323_pdata->keymap[i];
+		lm->keymap[i] = pdata->keymap[i];
 	}
 
-	if (lm8323_pdata->repeat)
+	if (pdata->repeat)
 		set_bit(EV_REP, idev->evbit);
 
 	lm->idev = idev;
-- 
1.6.1.3

[PATCH 2/5] input: lm8323: get rid of useless debug macro

[Felipe Balbi]

From: Felipe Balbi <felipe.balbi@nokia.com>

we can use dev_vdbg() which is only true when VERBOSE is
enabled.

Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
---
 drivers/input/keyboard/lm8323.c |   28 +++++++++++-----------------
 1 files changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 60abe61..0812bef 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -33,12 +33,6 @@
 #include <asm/mach-types.h>
 #include <asm/mach/irq.h>
 
-#ifdef VERBOSE
-#define debug dev_dbg
-#else
-#define debug(...)
-#endif
-
 /* Commands to send to the chip. */
 #define LM8323_CMD_READ_ID		0x80 /* Read chip ID. */
 #define LM8323_CMD_WRITE_CFG		0x81 /* Set configuration item. */
@@ -303,7 +297,7 @@ static void process_keys(struct lm8323_chip *lm)
 		s16 keycode = lm->keymap[key];
 
 		if (likely(keycode > 0)) {
-			debug(&lm->client->dev, "key 0x%02x %s\n", key,
+			dev_vdbg(&lm->client->dev, "key 0x%02x %s\n", key,
 			      isdown ? "down" : "up");
 			if (likely(lm->kp_enabled)) {
 				input_report_key(lm->idev, keycode, isdown);
@@ -337,13 +331,13 @@ static void lm8323_process_error(struct lm8323_chip *lm)
 
 	if (lm8323_read(lm, LM8323_CMD_READ_ERR, &error, 1) == 1) {
 		if (error & ERR_FIFOOVER)
-			debug(&lm->client->dev, "fifo overflow!\n");
+			dev_vdbg(&lm->client->dev, "fifo overflow!\n");
 		if (error & ERR_KEYOVR)
-			debug(&lm->client->dev, "more than two keys pressed\n");
+			dev_vdbg(&lm->client->dev, "more than two keys pressed\n");
 		if (error & ERR_CMDUNK)
-			debug(&lm->client->dev, "unknown command submitted\n");
+			dev_vdbg(&lm->client->dev, "unknown command submitted\n");
 		if (error & ERR_BADPAR)
-			debug(&lm->client->dev, "bad command parameter\n");
+			dev_vdbg(&lm->client->dev, "bad command parameter\n");
 	}
 }
 
@@ -408,10 +402,10 @@ static void lm8323_work(struct work_struct *work)
 			process_keys(lm);
 		if (ints & INT_ROTATOR) {
 			/* We don't currently support the rotator. */
-			debug(&lm->client->dev, "rotator fired\n");
+			dev_vdbg(&lm->client->dev, "rotator fired\n");
 		}
 		if (ints & INT_ERROR) {
-			debug(&lm->client->dev, "error!\n");
+			dev_vdbg(&lm->client->dev, "error!\n");
 			lm8323_process_error(lm);
 		}
 		if (ints & INT_NOINIT) {
@@ -420,15 +414,15 @@ static void lm8323_work(struct work_struct *work)
 			lm8323_configure(lm);
 		}
 		if (ints & INT_PWM1) {
-			debug(&lm->client->dev, "pwm1 engine completed\n");
+			dev_vdbg(&lm->client->dev, "pwm1 engine completed\n");
 			pwm_done(&lm->pwm1);
 		}
 		if (ints & INT_PWM2) {
-			debug(&lm->client->dev, "pwm2 engine completed\n");
+			dev_vdbg(&lm->client->dev, "pwm2 engine completed\n");
 			pwm_done(&lm->pwm2);
 		}
 		if (ints & INT_PWM3) {
-			debug(&lm->client->dev, "pwm3 engine completed\n");
+			dev_vdbg(&lm->client->dev, "pwm3 engine completed\n");
 			pwm_done(&lm->pwm3);
 		}
 	}
@@ -714,7 +708,7 @@ static int lm8323_probe(struct i2c_client *client,
 		lm->size_x = 12;
 	}
 
-	debug(&c->dev, "Keypad size: %d x %d\n", lm->size_x, lm->size_y);
+	dev_vdbg(&client->dev, "Keypad size: %d x %d\n", lm->size_x, lm->size_y);
 
 	lm->debounce_time = pdata->debounce_time;
 	if (lm->debounce_time == 0) /* Default. */
-- 
1.6.1.3

[PATCH 3/5] input: lm8323: general clean up

[Felipe Balbi]

From: Felipe Balbi <felipe.balbi@nokia.com>

This patch cleans up lm8323 driver a little bit:

- don't include <asm/mach-types.h> nor <asm/mach/irq.h>
- remove #define DRIVER_NAME
- don't try to fix pdata if it comes wrong, return -errno
- remove __devexit from remove() call
- move module_init() and module_exit() closer to their arguments
- add missing fields to n800's lm8323's pdata

Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
---
 arch/arm/mach-omap2/board-n800.c |   14 ++++++---
 drivers/input/keyboard/lm8323.c  |   51 ++++++++++++++-----------------------
 2 files changed, 28 insertions(+), 37 deletions(-)

diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c
index b38b295..fe6e5c9 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -111,12 +111,16 @@ static s16 rx44_keymap[LM8323_KEYMAP_SIZE] = {
 };
 
 static struct lm8323_platform_data lm8323_pdata = {
-	.repeat = 0, /* Repeat is handled in userspace for now. */
-	.keymap = rx44_keymap,
-
-	.name = "Internal keyboard",
-	.pwm1_name = "keyboard",
-	.pwm2_name = "cover",
+	.repeat		= 0, /* Repeat is handled in userspace for now. */
+	.keymap		= rx44_keymap,
+	.size_x		= 8,
+	.size_y		= 8,
+	.debounce_time	= 12,
+	.active_time	= 500,
+
+	.name		= "Internal keyboard",
+	.pwm1_name	= "keyboard",
+	.pwm2_name	= "cover",
 };
 #endif
 
diff --git a/drivers/input/keyboard/lm8323.c b/drivers/input/keyboard/lm8323.c
index 0812bef..27da93c 100644
--- a/drivers/input/keyboard/lm8323.c
+++ b/drivers/input/keyboard/lm8323.c
@@ -30,9 +30,6 @@
 #include <linux/leds.h>
 #include <linux/i2c/lm8323.h>
 
-#include <asm/mach-types.h>
-#include <asm/mach/irq.h>
-
 /* Commands to send to the chip. */
 #define LM8323_CMD_READ_ID		0x80 /* Read chip ID. */
 #define LM8323_CMD_WRITE_CFG		0x81 /* Set configuration item. */
@@ -127,8 +124,6 @@
 /* Send trigger.  Argument is same as PWM_WAIT_TRIG. */
 #define PWM_SEND_TRIG(chans)		(0xe000 | ((chans) & 0x7))
 
-#define DRIVER_NAME  "lm8323"
-
 struct lm8323_pwm {
 	int			id;
 	int			enabled;
@@ -671,7 +666,7 @@ static ssize_t lm8323_set_disable(struct device *dev,
 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)
+		const struct i2c_device_id *id)
 {
 	struct lm8323_platform_data *pdata;
 	struct input_dev *idev;
@@ -687,40 +682,32 @@ static int lm8323_probe(struct i2c_client *client,
 	i2c_set_clientdata(client, lm);
 	lm->client = client;
 	pdata = client->dev.platform_data;
-	if (!pdata)
-		return -EINVAL; /* ? */
+	if (!pdata || !pdata->size_x || !pdata->size_y) {
+		dev_err(&client->dev, "missing platform_data\n");
+		err = -EINVAL;
+		goto fail2;
+	}
 
 	lm->size_x = pdata->size_x;
-	if (lm->size_x == 0) {
-		lm->size_x = 8;
-	} else if (lm->size_x > 8) {
+	if (lm->size_x > 8) {
 		dev_err(&client->dev, "invalid x size %d specified\n",
 				lm->size_x);
-		lm->size_x = 8;
+		err = -EINVAL;
+		goto fail2;
 	}
 
 	lm->size_y = pdata->size_y;
-	if (lm->size_y == 0) {
-		lm->size_y = 12;
-	} else if (lm->size_y > 12) {
+	if (lm->size_y > 12) {
 		dev_err(&client->dev, "invalid y size %d specified\n",
 				lm->size_y);
-		lm->size_x = 12;
+		err = -EINVAL;
+		goto fail2;
 	}
 
 	dev_vdbg(&client->dev, "Keypad size: %d x %d\n", lm->size_x, lm->size_y);
 
 	lm->debounce_time = pdata->debounce_time;
-	if (lm->debounce_time == 0) /* Default. */
-		lm->debounce_time = 12;
-	else if (lm->debounce_time == -1) /* Disable debounce. */
-		lm->debounce_time = 0;
-
 	lm->active_time = pdata->active_time;
-	if (lm->active_time == 0) /* Default. */
-		lm->active_time = 500;
-	else if (lm->active_time == -1) /* Disable sleep. */
-		lm->active_time = 0;
 
 	lm8323_reset(lm);
 
@@ -760,7 +747,7 @@ static int lm8323_probe(struct i2c_client *client,
 
 	err = request_irq(client->irq, lm8323_irq,
 			  IRQF_TRIGGER_FALLING | IRQF_DISABLED |
-			  IRQF_SAMPLE_RANDOM, DRIVER_NAME, lm);
+			  IRQF_SAMPLE_RANDOM, "lm8323", lm);
 	if (err) {
 		dev_err(&client->dev, "could not get IRQ %d\n", client->irq);
 		goto fail6;
@@ -774,7 +761,7 @@ static int lm8323_probe(struct i2c_client *client,
 		goto fail7;
 
 	idev = input_allocate_device();
-	if (idev == NULL) {
+	if (!idev) {
 		err = -ENOMEM;
 		goto fail8;
 	}
@@ -892,16 +879,16 @@ static int lm8323_resume(struct i2c_client *client)
 }
 
 static const struct i2c_device_id lm8323_id[] = {
-	{ DRIVER_NAME, 0 },
+	{ "lm8323", 0 },
 	{ }
 };
 
 static struct i2c_driver lm8323_i2c_driver = {
 	.driver = {
-		.name	 = DRIVER_NAME,
+		.name	 = "lm8323",
 	},
 	.probe		= lm8323_probe,
-	.remove		= __devexit_p(lm8323_remove),
+	.remove		= lm8323_remove,
 	.suspend	= lm8323_suspend,
 	.resume		= lm8323_resume,
 	.id_table	= lm8323_id,
@@ -912,15 +899,15 @@ static int __init lm8323_init(void)
 {
 	return i2c_add_driver(&lm8323_i2c_driver);
 }
+module_init(lm8323_init);
 
 static void __exit lm8323_exit(void)
 {
 	i2c_del_driver(&lm8323_i2c_driver);
 }
+module_exit(lm8323_exit);
 
 MODULE_AUTHOR("Timo O. Karjalainen <timo.o.karjalainen@nokia.com>, Daniel Stone");
 MODULE_DESCRIPTION("LM8323 keypad driver");
 MODULE_LICENSE("GPL");
 
-module_init(lm8323_init);
-module_exit(lm8323_exit);
-- 
1.6.1.3

[PATCH 4/5] input: lm8323: prefix led name

[Felipe Balbi]

From: Felipe Balbi <felipe.balbi@nokia.com>

Prefix led name with machine name to avoid sysfs name
conflicts. It's minor and impossible to happen on n810
by now, but still let's try to keep good practices
while coding.

Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
---
 arch/arm/mach-omap2/board-n800.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-n800.c b/arch/arm/mach-omap2/board-n800.c
index fe6e5c9..6e34d80 100644
--- a/arch/arm/mach-omap2/board-n800.c
+++ b/arch/arm/mach-omap2/board-n800.c
@@ -119,8 +119,8 @@ static struct lm8323_platform_data lm8323_pdata = {
 	.active_time	= 500,
 
 	.name		= "Internal keyboard",
-	.pwm1_name	= "keyboard",
-	.pwm2_name	= "cover",
+	.pwm1_name	= "n810::keyboard",
+	.pwm2_name	= "n810::cover",
 };
 #endif
 
-- 
1.6.1.3

[PATCH 5/5] input: keyboard: removed unused lm8323_set_platform_data

[Felipe Balbi]

that's unused prototype, remove it.

Signed-off-by: Felipe Balbi <me@felipebalbi.com>
---
 include/linux/i2c/lm8323.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/linux/i2c/lm8323.h b/include/linux/i2c/lm8323.h
index 17d6b33..5eae5cc 100644
--- a/include/linux/i2c/lm8323.h
+++ b/include/linux/i2c/lm8323.h
@@ -32,6 +32,4 @@ struct lm8323_platform_data {
 	char *name; /* Device name. */
 };
 
-void __init lm8323_set_platform_data(struct lm8323_platform_data *pdata);
-
 #endif /* __LINUX_LM8323_H */
-- 
1.6.1.3

Re: [PATCH 0/5] [RESEND] lm8323 patches

[Felipe Balbi]

On Thu, Feb 19, 2009 at 02:29:38PM +0200, Felipe Balbi wrote:
> Hi Tony,
> 
> the final version is already going to mainline via linux-input,
> you might wanna apply these to l-o to avoid conflicts later.

mainline had a few comments to this driver which will come as an extra
cleanup patch since there's no functionality change, only style changes
so far.

These should be safe to apply.

-- 
balbi

Re: [PATCH 0/5] [RESEND] lm8323 patches

[Tony Lindgren]

* Felipe Balbi <me@felipebalbi.com> [090219 12:58]:
> On Thu, Feb 19, 2009 at 02:29:38PM +0200, Felipe Balbi wrote:
> > Hi Tony,
> > 
> > the final version is already going to mainline via linux-input,
> > you might wanna apply these to l-o to avoid conflicts later.
> 
> mainline had a few comments to this driver which will come as an extra
> cleanup patch since there's no functionality change, only style changes
> so far.
> 
> These should be safe to apply.

OK, will push today.

Tony

ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Thu, Feb 19, 2009 at 01:04:30PM -0800, Tony Lindgren wrote:
> * Felipe Balbi <me@felipebalbi.com> [090219 12:58]:
> > On Thu, Feb 19, 2009 at 02:29:38PM +0200, Felipe Balbi wrote:
> > > Hi Tony,
> > > 
> > > the final version is already going to mainline via linux-input,
> > > you might wanna apply these to l-o to avoid conflicts later.
> > 
> > mainline had a few comments to this driver which will come as an extra
> > cleanup patch since there's no functionality change, only style changes
> > so far.
> > 
> > These should be safe to apply.
> 
> OK, will push today.

Cool thanks, now that we're in the "push drivers upstream season", what
abou the ehci driver ? Did you get any patches from TI tony ? I asked
you to drop some patches from me because they said they would come up
with a better solution. If I get a board to test ehci, I'll push that
driver upstream as well, it's been too long waiting and TI still didn't
give us the patches for ehci, nor ohci.

-- 
balbi

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Tony Lindgren]

* Felipe Balbi <me@felipebalbi.com> [090219 13:19]:
> On Thu, Feb 19, 2009 at 01:04:30PM -0800, Tony Lindgren wrote:
> > * Felipe Balbi <me@felipebalbi.com> [090219 12:58]:
> > > On Thu, Feb 19, 2009 at 02:29:38PM +0200, Felipe Balbi wrote:
> > > > Hi Tony,
> > > > 
> > > > the final version is already going to mainline via linux-input,
> > > > you might wanna apply these to l-o to avoid conflicts later.
> > > 
> > > mainline had a few comments to this driver which will come as an extra
> > > cleanup patch since there's no functionality change, only style changes
> > > so far.
> > > 
> > > These should be safe to apply.
> > 
> > OK, will push today.
> 
> Cool thanks, now that we're in the "push drivers upstream season", what
> abou the ehci driver ? Did you get any patches from TI tony ? I asked
> you to drop some patches from me because they said they would come up
> with a better solution. If I get a board to test ehci, I'll push that
> driver upstream as well, it's been too long waiting and TI still didn't
> give us the patches for ehci, nor ohci.

No patches from TI :( It would be nice to get that driver into the
out of the linux-omap tree.

Tony

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Thu, Feb 19, 2009 at 01:29:27PM -0800, Tony Lindgren wrote:
> * Felipe Balbi <me@felipebalbi.com> [090219 13:19]:
> > On Thu, Feb 19, 2009 at 01:04:30PM -0800, Tony Lindgren wrote:
> > > * Felipe Balbi <me@felipebalbi.com> [090219 12:58]:
> > > > On Thu, Feb 19, 2009 at 02:29:38PM +0200, Felipe Balbi wrote:
> > > > > Hi Tony,
> > > > > 
> > > > > the final version is already going to mainline via linux-input,
> > > > > you might wanna apply these to l-o to avoid conflicts later.
> > > > 
> > > > mainline had a few comments to this driver which will come as an extra
> > > > cleanup patch since there's no functionality change, only style changes
> > > > so far.
> > > > 
> > > > These should be safe to apply.
> > > 
> > > OK, will push today.
> > 
> > Cool thanks, now that we're in the "push drivers upstream season", what
> > abou the ehci driver ? Did you get any patches from TI tony ? I asked
> > you to drop some patches from me because they said they would come up
> > with a better solution. If I get a board to test ehci, I'll push that
> > driver upstream as well, it's been too long waiting and TI still didn't
> > give us the patches for ehci, nor ohci.
> 
> No patches from TI :( It would be nice to get that driver into the
> out of the linux-omap tree.

I could patch but wouldn't have how to test it :-(

My beagle doesn't have ehci port, too bad.

-- 
balbi

RE: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Gadiyar, Anand]

On Friday Feb 20, 2009 Felipe Balbi wrote:
> > >
> > > Cool thanks, now that we're in the "push drivers upstream season", what
> > > abou the ehci driver ? Did you get any patches from TI tony ? I asked
> > > you to drop some patches from me because they said they would come up
> > > with a better solution. If I get a board to test ehci, I'll push that
> > > driver upstream as well, it's been too long waiting and TI still didn't
> > > give us the patches for ehci, nor ohci.
> >
> > No patches from TI :( It would be nice to get that driver into the
> > out of the linux-omap tree.
> 
> I could patch but wouldn't have how to test it :-(
> 
> My beagle doesn't have ehci port, too bad.

I've got the hardware. If you want to fix up that driver, I can test it for you.

- Anand

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Steve Sakoman]

On Thu, Feb 19, 2009 at 1:29 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Felipe Balbi <me@felipebalbi.com> [090219 13:19]:
>> On Thu, Feb 19, 2009 at 01:04:30PM -0800, Tony Lindgren wrote:
>> > * Felipe Balbi <me@felipebalbi.com> [090219 12:58]:
>> > > On Thu, Feb 19, 2009 at 02:29:38PM +0200, Felipe Balbi wrote:
>> > > > Hi Tony,
>> > > >
>> > > > the final version is already going to mainline via linux-input,
>> > > > you might wanna apply these to l-o to avoid conflicts later.
>> > >
>> > > mainline had a few comments to this driver which will come as an extra
>> > > cleanup patch since there's no functionality change, only style changes
>> > > so far.
>> > >
>> > > These should be safe to apply.
>> >
>> > OK, will push today.
>>
>> Cool thanks, now that we're in the "push drivers upstream season", what
>> abou the ehci driver ? Did you get any patches from TI tony ? I asked
>> you to drop some patches from me because they said they would come up
>> with a better solution. If I get a board to test ehci, I'll push that
>> driver upstream as well, it's been too long waiting and TI still didn't
>> give us the patches for ehci, nor ohci.
>
> No patches from TI :( It would be nice to get that driver into the
> out of the linux-omap tree.

EHCI omap driver definitely needs some work - there is machine
specific stuff in there that rightfully belongs in platform data.  I
haven't had time to work on it :-(

Steve

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Thu, Feb 19, 2009 at 02:43:36PM -0800, Steve Sakoman wrote:
> EHCI omap driver definitely needs some work - there is machine
> specific stuff in there that rightfully belongs in platform data.  I
> haven't had time to work on it :-(

For sure, and there's still workaround for clk framework stuff that
should already move there.

I'll try to start with some cleanups already during this weekend (yeah,
I've got no life :-p) and post as RFT asap. After the cleanups are ok,
then I'll start moving platform code out of there and for the clock
workarounds I'll need help from Paul Walmsley, probably :-)

-- 
balbi

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Grazvydas Ignotas]

On Fri, Feb 20, 2009 at 12:46 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> On Thu, Feb 19, 2009 at 02:43:36PM -0800, Steve Sakoman wrote:
>> EHCI omap driver definitely needs some work - there is machine
>> specific stuff in there that rightfully belongs in platform data.  I
>> haven't had time to work on it :-(
>
> For sure, and there's still workaround for clk framework stuff that
> should already move there.
>
> I'll try to start with some cleanups already during this weekend (yeah,
> I've got no life :-p) and post as RFT asap. After the cleanups are ok,
> then I'll start moving platform code out of there and for the clock
> workarounds I'll need help from Paul Walmsley, probably :-)

Great, I'll be watching the list and gladly test them on pandora too.
It would be nice to have those remote wakeup issues [1] sorted out
too.

1: http://marc.info/?l=linux-omap&m=122911571519657&w=2

RE: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Gadiyar, Anand]

On Friday Feb 20, 2009 Grazvydas Ignotas wrote:
> On Fri, Feb 20, 2009 at 12:46 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> > On Thu, Feb 19, 2009 at 02:43:36PM -0800, Steve Sakoman wrote:
> >> EHCI omap driver definitely needs some work - there is machine
> >> specific stuff in there that rightfully belongs in platform data.  I
> >> haven't had time to work on it :-(
> >
> > For sure, and there's still workaround for clk framework stuff that
> > should already move there.
> >
> > I'll try to start with some cleanups already during this weekend (yeah,
> > I've got no life :-p) and post as RFT asap. After the cleanups are ok,
> > then I'll start moving platform code out of there and for the clock
> > workarounds I'll need help from Paul Walmsley, probably :-)
> 
> Great, I'll be watching the list and gladly test them on pandora too.
> It would be nice to have those remote wakeup issues [1] sorted out
> too.
> 
> 1: http://marc.info/?l=linux-omap&m=122911571519657&w=2


Sorry, that is not something that will be fixed in ES3.1. It also affects
suspend-resume, not just remote-wakeup.

However, there is a software workaround that is being tested right now
- the one mentioned in the link does not work reliably. The new
workaround should be ready shortly (maybe after Felipe is done with
the cleanups he plans).

- Anand

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Fri, Feb 20, 2009 at 11:44:25AM +0100, Anand Gadiyar wrote:
> On Friday Feb 20, 2009 Grazvydas Ignotas wrote:
> > On Fri, Feb 20, 2009 at 12:46 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> > > On Thu, Feb 19, 2009 at 02:43:36PM -0800, Steve Sakoman wrote:
> > >> EHCI omap driver definitely needs some work - there is machine
> > >> specific stuff in there that rightfully belongs in platform data.  I
> > >> haven't had time to work on it :-(
> > >
> > > For sure, and there's still workaround for clk framework stuff that
> > > should already move there.
> > >
> > > I'll try to start with some cleanups already during this weekend (yeah,
> > > I've got no life :-p) and post as RFT asap. After the cleanups are ok,
> > > then I'll start moving platform code out of there and for the clock
> > > workarounds I'll need help from Paul Walmsley, probably :-)
> >
> > Great, I'll be watching the list and gladly test them on pandora too.
> > It would be nice to have those remote wakeup issues [1] sorted out
> > too.
> >
> > 1: http://marc.info/?l=linux-omap&m=122911571519657&w=2
> 
> 
> Sorry, that is not something that will be fixed in ES3.1. It also affects
> suspend-resume, not just remote-wakeup.
> 
> However, there is a software workaround that is being tested right now
> - the one mentioned in the link does not work reliably. The new
> workaround should be ready shortly (maybe after Felipe is done with
> the cleanups he plans).

well, it's been about 5 months since you said TI would be doing such
cleanups, I've even had my patches dropped at that time because of that
and till now nothing happened. About the workaround, I'd rather read the
errata myself and implement it.

-- 
balbi

RE: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Gadiyar, Anand]

<snip> 

> well, it's been about 5 months since you said TI would be doing such
> cleanups, I've even had my patches dropped at that time because of that
> and till now nothing happened. About the workaround, I'd rather read the
> errata myself and implement it.

Well, I've said time and again that I haven't been able to get around to it.

You can read the errata yourself and implement it if you wish. Frankly,
I don't give a damn.

I've spent the last five months finding the workarounds for all the
erratas affecting EHCI, which is __the whole reason__ why I have not
been able to fix up the EHCI driver.

- Anand

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Fri, Feb 20, 2009 at 01:40:32PM +0100, Anand Gadiyar wrote:
> <snip>
> 
> > well, it's been about 5 months since you said TI would be doing such
> > cleanups, I've even had my patches dropped at that time because of that
> > and till now nothing happened. About the workaround, I'd rather read the
> > errata myself and implement it.
> 
> Well, I've said time and again that I haven't been able to get around to it.
> 
> You can read the errata yourself and implement it if you wish. Frankly,
> I don't give a damn.
> 
> I've spent the last five months finding the workarounds for all the
> erratas affecting EHCI, which is __the whole reason__ why I have not
> been able to fix up the EHCI driver.

A quick mail explaining that you wouldn't be able to fix ehci at that
time would've been enough to avoid it. Then we could have gotten it
cleaned up and then just integrate your latest workarounds. Still, the
driver will need lots of cleanups before we think about adding
workarounds and we have to think about how to integrate the workarounds
for different ehci/omap silicon revisions, etc...

Anyways, I'll keep going with my cleanups and when I get a platform to
test ehci, I'll try to test the patches and keep going with the
workarounds.

-- 
balbi

RE: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Gadiyar, Anand]

> On Fri, Feb 20, 2009 at 01:40:32PM +0100, Anand Gadiyar wrote:
> > <snip>
> > 
> > > well, it's been about 5 months since you said TI would be doing such
> > > cleanups, I've even had my patches dropped at that time because of that
> > > and till now nothing happened. About the workaround, I'd rather read the
> > > errata myself and implement it.
> > 
> > Well, I've said time and again that I haven't been able to get around to it.
> > 
> > You can read the errata yourself and implement it if you wish. Frankly,
> > I don't give a damn.
> > 
> > I've spent the last five months finding the workarounds for all the
> > erratas affecting EHCI, which is __the whole reason__ why I have not
> > been able to fix up the EHCI driver.
> 
> A quick mail explaining that you wouldn't be able to fix ehci at that
> time would've been enough to avoid it. Then we could have gotten it
> cleaned up and then just integrate your latest workarounds. Still, the
> driver will need lots of cleanups before we think about adding
> workarounds and we have to think about how to integrate the workarounds
> for different ehci/omap silicon revisions, etc...

Well, the way it went was I discovered errata after errata. Everytime I thought
this is the last one and I can finally get around to that cleanup, three days
later I would end up working on the next failure.

I've spent so much time on it, I'm sick of it.


So here's the quick mail you want:
"I may or may not be able to clean up this driver in the near future. Felipe
Balbi graciously agress to do it for us. So I am pleased to announce he will
clean up this driver and send it upstream. If he needs any help with this, I
will try to provide it to him (or anyone else for that matter) on a best-effort
basis. Good luck."


> 
> Anyways, I'll keep going with my cleanups and when I get a platform to
> test ehci, I'll try to test the patches and keep going with the
> workarounds.

If you want help with testing, I can give it to you. If not, you can test
it yourself - I couldn't care less.

- Anand

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Fri, Feb 20, 2009 at 01:57:14PM +0100, Anand Gadiyar wrote:
> > On Fri, Feb 20, 2009 at 01:40:32PM +0100, Anand Gadiyar wrote:
> > > <snip>
> > >
> > > > well, it's been about 5 months since you said TI would be doing such
> > > > cleanups, I've even had my patches dropped at that time because of that
> > > > and till now nothing happened. About the workaround, I'd rather read the
> > > > errata myself and implement it.
> > >
> > > Well, I've said time and again that I haven't been able to get around to it.
> > >
> > > You can read the errata yourself and implement it if you wish. Frankly,
> > > I don't give a damn.
> > >
> > > I've spent the last five months finding the workarounds for all the
> > > erratas affecting EHCI, which is __the whole reason__ why I have not
> > > been able to fix up the EHCI driver.
> >
> > A quick mail explaining that you wouldn't be able to fix ehci at that
> > time would've been enough to avoid it. Then we could have gotten it
> > cleaned up and then just integrate your latest workarounds. Still, the
> > driver will need lots of cleanups before we think about adding
> > workarounds and we have to think about how to integrate the workarounds
> > for different ehci/omap silicon revisions, etc...
> 
> Well, the way it went was I discovered errata after errata. Everytime I thought
> this is the last one and I can finally get around to that cleanup, three days
> later I would end up working on the next failure.
> 
> I've spent so much time on it, I'm sick of it.

Don't worry, you're not the only one TIred here...

> So here's the quick mail you want:
> "I may or may not be able to clean up this driver in the near future. Felipe
> Balbi graciously agress to do it for us. So I am pleased to announce he will
> clean up this driver and send it upstream. If he needs any help with this, I
> will try to provide it to him (or anyone else for that matter) on a best-effort
> basis. Good luck."
> 
> 
> >
> > Anyways, I'll keep going with my cleanups and when I get a platform to
> > test ehci, I'll try to test the patches and keep going with the
> > workarounds.
> 
> If you want help with testing, I can give it to you. If not, you can test
> it yourself - I couldn't care less.

And you want me to agree with it ? I really was hoping we could work
together with TI but seems I'm the only one who still believes in that.

As you said yourself, you couldn't care less right ? You couldn't care
less if the driver works or not, you couldn't care less if we have good
omap support out of mainline kernel, you couldn't care less if the
driver is readable or not, etc etc etc. I imagine if all of us would be
taking the same behavior as you are...

Well, I'm not here to flood the list discussing this kinds of issues with you.

-- 
balbi

RE: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Gadiyar, Anand]

> Don't worry, you're not the only one TIred here...

Grrr. I'm in no mood to take any TI puns right now. That was unwarranted.

> 
> > So here's the quick mail you want:
> > "I may or may not be able to clean up this driver in the near future. Felipe
> > Balbi graciously agress to do it for us. So I am pleased to  announce he will
> > clean up this driver and send it upstream. If he needs any help with this, I
> > will try to provide it to him (or anyone else for that matter) on a best-effort
> > basis. Good luck."
> > 
> > 
> > >
> > > Anyways, I'll keep going with my cleanups and when I get a platform to
> > > test ehci, I'll try to test the patches and keep going with the
> > > workarounds.
> > 
> > If you want help with testing, I can give it to you. If not, you can test
> > it yourself - I couldn't care less.
> 
> And you want me to agree with it ? I really was hoping we could work
> together with TI but seems I'm the only one who still believes in that.

I made that offer - so there is at least one other believer of working together.
You're the one that wants to do this on your own - and I'm okay with that.


> 
> As you said yourself, you couldn't care less right ? You couldn't care
> less if the driver works or not, you couldn't care less if we have good
> omap support out of mainline kernel, you couldn't care less if the
> driver is readable or not, etc etc etc.

That's not true. I do care. It __is__ important to me that OMAP support goes
to mainline. And I do not like it that it hasn't happened yet. Sorry.

What happened with EHCI here is kind of similar to what you've done with MUSB patches recently anyway.

> I imagine if all of us would be
> taking the same behavior as you are...

I don't understand what you mean, but I'm guessing it doesn't matter.

> 
> Well, I'm not here to flood the list discussing this kinds of 
> issues with you.

Standard behavior for you. That's the way you end all discussions that go
beyond 5 mails!

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Fri, Feb 20, 2009 at 02:23:33PM +0100, Anand Gadiyar wrote:
> That's not true. I do care. It __is__ important to me that OMAP support goes
> to mainline. And I do not like it that it hasn't happened yet. Sorry.
> 
> What happened with EHCI here is kind of similar to what you've done with MUSB patches recently anyway.

sure... but then Dave helped right... We had some discussions off list
in order for that to happen.

> > Well, I'm not here to flood the list discussing this kinds of
> > issues with you.
> 
> Standard behavior for you. That's the way you end all discussions that go
> beyond 5 mails!

yeah... for sure. If you wanna keep discussing it, just keep sending
your mails...

-- 
balbi

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Contreras]

On Fri, Feb 20, 2009 at 3:23 PM, Gadiyar, Anand <gadiyar@ti.com> wrote:
>> Don't worry, you're not the only one TIred here...
>
> Grrr. I'm in no mood to take any TI puns right now. That was unwarranted.

Was it? I agree with Felipe (Balbi) there's more people tired of this
stuff. I don't know which way you would have preferred him to express
his frustration, or maybe you don't want any negative feedback at all.

>> > So here's the quick mail you want:
>> > "I may or may not be able to clean up this driver in the near future. Felipe
>> > Balbi graciously agress to do it for us. So I am pleased to  announce he will
>> > clean up this driver and send it upstream. If he needs any help with this, I
>> > will try to provide it to him (or anyone else for that matter) on a best-effort
>> > basis. Good luck."
>> >
>> >
>> > >
>> > > Anyways, I'll keep going with my cleanups and when I get a platform to
>> > > test ehci, I'll try to test the patches and keep going with the
>> > > workarounds.
>> >
>> > If you want help with testing, I can give it to you. If not, you can test
>> > it yourself - I couldn't care less.
>>
>> And you want me to agree with it ? I really was hoping we could work
>> together with TI but seems I'm the only one who still believes in that.
>
> I made that offer - so there is at least one other believer of working together.
> You're the one that wants to do this on your own - and I'm okay with that.

I don't know the history of this patch series, so perhaps I'm
misinterpreting this, but it looks like he submitted some patches and
you said it was the wrong way to do it and *you* would come up with a
proper patch.

A collaborative way to fix this issue would be to comment on the
specific pieces of code you would want changed, perhaps even re-send
the patches with the suggested changes so other people could review,
comment, test, etc. This would probably generate a few rounds of patch
series until it gets finally merged.

Instead you said you where going to provide a proper fix and never did
so. There might be valid reasons for not coming up with the patches
(like the difficulty of the task), but there's no excuse for the lack
of communication.

>> As you said yourself, you couldn't care less right ? You couldn't care
>> less if the driver works or not, you couldn't care less if we have good
>> omap support out of mainline kernel, you couldn't care less if the
>> driver is readable or not, etc etc etc.
>
> That's not true. I do care. It __is__ important to me that OMAP support goes
> to mainline. And I do not like it that it hasn't happened yet. Sorry.

Personally I find your position to be not collaborative at all. Do you
care or not? If you do, you could test Felipe's patches, review,
comment, rewrite, etc.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Anand Gadiyar]

On Sun, Feb 22, 2009 at 7:21 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Fri, Feb 20, 2009 at 3:23 PM, Gadiyar, Anand <gadiyar@ti.com> wrote:
>>> Don't worry, you're not the only one TIred here...
>>
>> Grrr. I'm in no mood to take any TI puns right now. That was unwarranted.
>
> Was it? I agree with Felipe (Balbi) there's more people tired of this
> stuff. I don't know which way you would have preferred him to express
> his frustration, or maybe you don't want any negative feedback at all.
>

This comment was specific to the pun on TI. That pun was completely
unwarranted. He's not the only one frustrated here.

Just because I have an @ti.com id is not reason enough to blame all of
TI. There are people in TI doing real work.


>>> > So here's the quick mail you want:
>>> > "I may or may not be able to clean up this driver in the near future. Felipe
>>> > Balbi graciously agress to do it for us. So I am pleased to  announce he will
>>> > clean up this driver and send it upstream. If he needs any help with this, I
>>> > will try to provide it to him (or anyone else for that matter) on a best-effort
>>> > basis. Good luck."
>>> >
>>> >
>>> > >
>>> > > Anyways, I'll keep going with my cleanups and when I get a platform to
>>> > > test ehci, I'll try to test the patches and keep going with the
>>> > > workarounds.
>>> >
>>> > If you want help with testing, I can give it to you. If not, you can test
>>> > it yourself - I couldn't care less.
>>>
>>> And you want me to agree with it ? I really was hoping we could work
>>> together with TI but seems I'm the only one who still believes in that.
>>
>> I made that offer - so there is at least one other believer of working together.
>> You're the one that wants to do this on your own - and I'm okay with that.
>
> I don't know the history of this patch series, so perhaps I'm
> misinterpreting this, but it looks like he submitted some patches and
> you said it was the wrong way to do it and *you* would come up with a
> proper patch.
>

Then I suggest you read up the history. You __are__ misinterpreting
this. He did not submit any patches. He had a list of some tens of
drivers that he was planning to send to mainline sometime last
September. I thought I'll save everyone some time and would take care
of sending in at least the EHCI part so he could concentrate on other
stuff that he was doing. Unfortunately, I got preempted more than
once.


> A collaborative way to fix this issue would be to comment on the
> specific pieces of code you would want changed, perhaps even re-send
> the patches with the suggested changes so other people could review,
> comment, test, etc. This would probably generate a few rounds of patch
> series until it gets finally merged.
>

I am not against collaboration. Felipe said on Friday that he could do
the cleanups but had no way of testing. I do not have the bandwidth to
do those changes myself, but I did offer to test it for him. If this
is not collaboration, I do not know what is.

Felipe got mad at me and said he would rather read the errata and
implement it himself. And my response to that is above. If he wants to
work on EHCI himself, that's great. It'll save me the trouble of
testing and I'm guessing we'll see him return to the list 6 months
from now, just like I did :)

Reading up just the mail exchanges we've had on Friday is sufficient
to show who wants to work alone and who wants to collaborate.


> Instead you said you where going to provide a proper fix and never did
> so. There might be valid reasons for not coming up with the patches
> (like the difficulty of the task), but there's no excuse for the lack
> of communication.
>
>>> As you said yourself, you couldn't care less right ? You couldn't care
>>> less if the driver works or not, you couldn't care less if we have good
>>> omap support out of mainline kernel, you couldn't care less if the
>>> driver is readable or not, etc etc etc.
>>
>> That's not true. I do care. It __is__ important to me that OMAP support goes
>> to mainline. And I do not like it that it hasn't happened yet. Sorry.
>
> Personally I find your position to be not collaborative at all. Do you
> care or not? If you do, you could test Felipe's patches, review,
> comment, rewrite, etc.


Read the history before making your comments dude. I __have__ offered
to test. I do intend to spend time reviewing - but I will not
guarantee it.

Felipe's the one that flew off the handle before I did. Personally, I
do not find it at all amusing that everytime someone @nokia.com gets
shouted at on-list by someone @ti.com, all Nokia-ites gang up on the
TI-er.

Give us a break. It's not like we are against working with the community.

- Anand

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

Hi,

not trying to keep the thread alive, but...

On Sun, Feb 22, 2009 at 09:29:30PM +0530, Anand Gadiyar wrote:
> Then I suggest you read up the history. You __are__ misinterpreting
> this. He did not submit any patches. He had a list of some tens of
> drivers that he was planning to send to mainline sometime last
> September. I thought I'll save everyone some time and would take care

http://marc.info/?l=linux-omap&m=122124472931396&w=2

I've even mailed you and/or Vikram 4 patches on ehci for you make your patches
on top of them.

(can't really remember if you or Vikram was working on that driver at
that time)

> of sending in at least the EHCI part so he could concentrate on other
> stuff that he was doing. Unfortunately, I got preempted more than
> once.

heh, I know how that feels...

-- 
balbi

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Anand Gadiyar]

On Sun, Feb 22, 2009 at 10:20 PM, Felipe Balbi <me@felipebalbi.com> wrote:
> Hi,
>
> not trying to keep the thread alive, but...
>
> On Sun, Feb 22, 2009 at 09:29:30PM +0530, Anand Gadiyar wrote:
>> Then I suggest you read up the history. You __are__ misinterpreting
>> this. He did not submit any patches. He had a list of some tens of
>> drivers that he was planning to send to mainline sometime last
>> September. I thought I'll save everyone some time and would take care
>
> http://marc.info/?l=linux-omap&m=122124472931396&w=2
>
> I've even mailed you and/or Vikram 4 patches on ehci for you make your patches
> on top of them.
>
> (can't really remember if you or Vikram was working on that driver at
> that time)

I must have missed the patchset, or I wasn't on the CC list. Anyway,
let's end this here and figure out how to get the driver functional,
cleaned-up and in mainline. I'm willing to help out in any way I can.

I've got hardware if you would like to test something. I've got a
decent bit of knowledge on the controller hardware, (plus tons of
knowledge on it's failings ;) )

Plus partially done work...

Let me know how you would like to go about this.

- Anand

P.S. I'm out of office taking my first break in months. I can only
start once I get back next week.

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Felipe Balbi]

On Sun, Feb 22, 2009 at 10:34:03PM +0530, Anand Gadiyar wrote:
> I must have missed the patchset, or I wasn't on the CC list. Anyway,
> let's end this here and figure out how to get the driver functional,
> cleaned-up and in mainline. I'm willing to help out in any way I can.
> 
> I've got hardware if you would like to test something. I've got a
> decent bit of knowledge on the controller hardware, (plus tons of
> knowledge on it's failings ;) )
> 
> Plus partially done work...
> 
> Let me know how you would like to go about this.

cool, mailed you a tarball with my preliminary patches. This should get
ehci better for the eyes and hopefully I got rid of all infinite loops.
Later I wanna work on getting AUTOIDLE re-enabled and get this driver
reach off mode.

> P.S. I'm out of office taking my first break in months. I can only
> start once I get back next week.

have fun ;-)

-- 
balbi

Re: ehci-omap patches (Was Re: [PATCH 0/5] [RESEND] lm8323 patches)

[Otto Solares]

On Fri, Feb 20, 2009 at 06:27:14PM +0530, Gadiyar, Anand wrote:
> ...
> If you want help with testing, I can give it to you. If not, you can test
> it yourself - I couldn't care less.

It would be nice to know if your venerable employer (TI) share your
opinion?...

-otto