2.6.19 + omap patch on the OSK

2.6.19 + omap patch on the OSK

[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?

Philip

Re: 2.6.19 + omap patch on the OSK

[tony]

* Philip Balister <philip@balister.org> [070102 12:03]:
> 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

Re: 2.6.19 + omap patch on the OSK

[Philip Balister]

tony@atomide.com wrote:
> * Philip Balister <philip@balister.org> [070102 12:03]:
>> 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.

Adding this patch resolved my problem.

Thanks,

Philip

Re: 2.6.19 + omap patch on the OSK

[Dirk Behme]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

tony@atomide.com 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>


[-- Attachment #2: i2c_zero_length_smbus_quick_hack_patch_new.txt --]
[-- Type: text/plain, Size: 1138 bytes --]

Index: linux-osk/drivers/i2c/busses/i2c-omap.c
===================================================================
--- linux-osk.orig/drivers/i2c/busses/i2c-omap.c
+++ 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


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: 2.6.19 + omap patch on the OSK

[Tony Lindgren]

* Dirk Behme <dirk.behme@googlemail.com> [070103 09:09]:
> tony@atomide.com 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