Skip to contentSkip to conversation

2.6.19 + omap patch on the OSK

DISCUSSION Philip Balister 3 participants 5 messages Jan 2, 2007 – Jan 3, 2007

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

I just built a 2.6.19 + omap patch kernel for my OSK. When I tried booting it, the kernel oopsed when it started ALSA. Has anyone booted an OSK using this kernel version?

Philip

#1 lore raw
Quoted 3 lines · Philip Balister

I just built a 2.6.19 + omap patch kernel for my OSK. When I tried booting it, the kernel oopsed when it started ALSA. Has anyone booted an OSK using this kernel version?

This is probably because of the zero byte scan missing from linux-omap tree as we're trying to sync things with mainline.

Please try this patch:

http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html

I'll apply it back to linux-omap tree as now there is a longer term solution with David Brownell's I2C patches that should eventually solve this problem for mainline kernel also.

Regards,

Tony

#2 lore raw
Quoted 6 lines · [email protected] wrote:
Quoted 1 line · Philip Balister

I just built a 2.6.19 + omap patch kernel for my OSK. When I tried booting it, the kernel oopsed when it started ALSA. Has anyone booted an OSK using this kernel version?

This is probably because of the zero byte scan missing from linux-omap tree as we're trying to sync things with mainline.

Quoted 7 lines

Please try this patch:

http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html

I'll apply it back to linux-omap tree as now there is a longer term solution with David Brownell's I2C patches that should eventually solve this problem for mainline kernel also.

Adding this patch resolved my problem.

Thanks,

Philip

#3 lore raw
In reply to [email protected]
Quoted 7 lines · [email protected] wrote:

Please try this patch:

http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html

I'll apply it back to linux-omap tree as now there is a longer term solution with David Brownell's I2C patches that should eventually solve this problem for mainline kernel also.

Looks like the removal of ~I2C_FUNC_SMBUS_QUICK was missed while applying it. Update of this in attachment.

-- cut --

ARM: OMAP: Remove ~I2C_FUNC_SMBUS_QUICK to make this hack working. Beautify #ifdef.

Signed-off-by Dirk Behme <dirk.behme_at_gmail.com>
drivers/i2c/busses/i2c-omap.c +11 -1
Index: linux-osk/drivers/i2c/busses/i2c-omap.c
===================================================================
@@ -36,6 +36,10 @@
 
 #include <asm/io.h>
 
+/* Hack to enable zero length transfers and smbus quick until clean fix
+   is available */
+#define OMAP_HACK
+
 /* timeout waiting for the controller to respond */
 #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
 
@@ -285,14 +289,16 @@ static int omap_i2c_xfer_msg(struct i2c_
 			     struct i2c_msg *msg, int stop)
 {
 	struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
+#ifdef OMAP_HACK
 	u8 zero_byte = 0;
+#endif
 	int r;
 	u16 w;
 
 	dev_dbg(dev->dev, "addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n",
 		msg->addr, msg->len, msg->flags, stop);
 
-#if 0
+#ifndef OMAP_HACK
 	if (msg->len == 0)
 		return -EINVAL;
 
@@ -406,7 +412,11 @@ out:
 static u32
 omap_i2c_func(struct i2c_adapter *adap)
 {
+#ifndef OMAP_HACK
 	return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
+#else
+	return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+#endif
 }
 
 static inline void
maintainer
#4 lore raw
Quoted 11 lines · Dirk Behme
Quoted 7 lines · [email protected] wrote:

Please try this patch:

http://linux.omap.com/pipermail/linux-omap-open-source/2006-October/008232.html

I'll apply it back to linux-omap tree as now there is a longer term solution with David Brownell's I2C patches that should eventually solve this problem for mainline kernel also.

Looks like the removal of ~I2C_FUNC_SMBUS_QUICK was missed while applying it. Update of this in attachment.

Thanks. I reverted my hack, and reapplied my patch merged to yours yours so we have a single hack patch to make merging easier.

Tony