linux-openmoko-2.6.28: Add 8 bug fixes cherry-picked from andy-tracking.

This will be obsolete once we go for a newer src rev.

9 files changed, 605 insertions, 1 deletions

diff --git a/packages/linux/linux-openmoko-2.6.28/0001-MERGE-via-pending-tracking-hist-subject-usb-gadget-r.patch b/packages/linux/linux-openmoko-2.6.28/0001-MERGE-via-pending-tracking-hist-subject-usb-gadget-r.patch
new file mode 100644
index 0000000000..c228396a81
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0001-MERGE-via-pending-tracking-hist-subject-usb-gadget-r.patch
@@ -0,0 +1,55 @@
+From f94d3fbb605ad16d701525502fbad114a950197c Mon Sep 17 00:00:00 2001
+From: merge <null@invalid>
+Date: Mon, 19 Jan 2009 23:03:59 +0000
+Subject: [PATCH 1/8] MERGE-via-pending-tracking-hist-subject-usb-gadget-rndis-send-
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: 8bit
+pending-tracking-hist top was subject-usb-gadget-rndis-send- / 3c29888770bfa8ce3a5e2ed590c3edb97ca4abaf ... parent commitmessage:
+From: Richard Röjfors <richard.rojfors@endian.se>
+Subject: USB: gadget rndis: send notifications
+
+X-Git-Tag: v2.6.28-rc6~2^2~2
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=ff3495052af48f7a2bf7961b131dc9e161dae19c;hp=9c264521a9f836541c122b00f505cfd60cc5bbb5
+
+USB: gadget rndis: send notifications
+
+It turns out that atomic_inc_return() returns the *new* value
+not the original one, so the logic in rndis_response_available()
+kept the first RNDIS response notification from getting out.
+This prevented interoperation with MS-Windows (but not Linux).
+
+Fix this to make RNDIS behave again.
+
+Signed-off-by: Richard Röjfors <richard.rojfors@endian.se>
+Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+---
+ drivers/usb/gadget/f_rndis.c |    3 +--
+ 1 files changed, 1 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
+index 659b3d9..428b599 100644
+--- a/drivers/usb/gadget/f_rndis.c
++++ b/drivers/usb/gadget/f_rndis.c
+@@ -172,7 +172,6 @@ static struct usb_interface_descriptor rndis_data_intf __initdata = {
+ 	.bDescriptorType =	USB_DT_INTERFACE,
+ 
+ 	/* .bInterfaceNumber = DYNAMIC */
+-	.bAlternateSetting =	1,
+ 	.bNumEndpoints =	2,
+ 	.bInterfaceClass =	USB_CLASS_CDC_DATA,
+ 	.bInterfaceSubClass =	0,
+@@ -303,7 +302,7 @@ static void rndis_response_available(void *_rndis)
+ 	__le32				*data = req->buf;
+ 	int				status;
+ 
+-	if (atomic_inc_return(&rndis->notify_count))
++	if (atomic_inc_return(&rndis->notify_count) != 1)
+ 		return;
+ 
+ 	/* Send RNDIS RESPONSE_AVAILABLE notification; a
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28/0002-MERGE-via-pending-tracking-hist-subject-usb-gadget-f.patch b/packages/linux/linux-openmoko-2.6.28/0002-MERGE-via-pending-tracking-hist-subject-usb-gadget-f.patch
new file mode 100644
index 0000000000..bfe9d08464
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0002-MERGE-via-pending-tracking-hist-subject-usb-gadget-f.patch
@@ -0,0 +1,50 @@
+From e4e155b8e3aeebb54b4295bce17ef5e85decd44d Mon Sep 17 00:00:00 2001
+From: merge <null@invalid>
+Date: Tue, 20 Jan 2009 10:40:16 +0000
+Subject: [PATCH 2/8] MERGE-via-pending-tracking-hist-subject-usb-gadget-fix-rndis-w
+pending-tracking-hist top was subject-usb-gadget-fix-rndis-w / 8a5ccc279cef316a16f921d7486f4a9efa234493 ... parent commitmessage:
+From: David Brownell <dbrownell@users.sourceforge.net>
+Subject: USB: gadget: fix rndis working at high speed
+
+X-Git-Tag: v2.6.28-rc9~8^2~7
+X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=7c12414955e9b44a3e33d54e578bf008caa4475d
+
+USB: gadget: fix rndis working at high speed
+
+Fix a bug specific to highspeed mode in the recently updated RNDIS
+support:  it wasn't setting up the high speed notification endpoint,
+which prevented high speed RNDIS links from working.
+
+Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
+Tested-by: Anand Gadiyar <gadiyar@ti.com>
+Cc: stable <stable@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+---
+ drivers/usb/gadget/f_rndis.c |    4 ++++
+ 1 files changed, 4 insertions(+), 0 deletions(-)
+
+diff --git a/drivers/usb/gadget/f_rndis.c b/drivers/usb/gadget/f_rndis.c
+index 428b599..3a8bb53 100644
+--- a/drivers/usb/gadget/f_rndis.c
++++ b/drivers/usb/gadget/f_rndis.c
+@@ -651,6 +651,8 @@ rndis_bind(struct usb_configuration *c, struct usb_function *f)
+ 				fs_in_desc.bEndpointAddress;
+ 		hs_out_desc.bEndpointAddress =
+ 				fs_out_desc.bEndpointAddress;
++		hs_notify_desc.bEndpointAddress =
++				fs_notify_desc.bEndpointAddress;
+ 
+ 		/* copy descriptors, and track endpoint copies */
+ 		f->hs_descriptors = usb_copy_descriptors(eth_hs_function);
+@@ -662,6 +664,8 @@ rndis_bind(struct usb_configuration *c, struct usb_function *f)
+ 				f->hs_descriptors, &hs_in_desc);
+ 		rndis->hs.out = usb_find_endpoint(eth_hs_function,
+ 				f->hs_descriptors, &hs_out_desc);
++		rndis->hs.notify = usb_find_endpoint(eth_hs_function,
++				f->hs_descriptors, &hs_notify_desc);
+ 	}
+ 
+ 	rndis->port.open = rndis_open;
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28/0003-consider-alrm-enable-in-pcf50633_rtc_set_alarm.patch b/packages/linux/linux-openmoko-2.6.28/0003-consider-alrm-enable-in-pcf50633_rtc_set_alarm.patch
new file mode 100644
index 0000000000..48cf384c67
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0003-consider-alrm-enable-in-pcf50633_rtc_set_alarm.patch
@@ -0,0 +1,52 @@
+From 72669a7c7637dba5f4f2ae4a8301cf9560f0a807 Mon Sep 17 00:00:00 2001
+From: Werner Almesberger <werner@openmoko.org>
+Date: Fri, 30 Jan 2009 08:07:27 +0000
+Subject: [PATCH 3/8] consider alrm->enable in pcf50633_rtc_set_alarm
+
+Backported to .28, original message below:
+
+Hi Balaji,
+
+Mickey mentioned to me that he had trouble with the RTC wakeup interrupt.
+I had a quick look at the problem and it seems that alrm->enable doesn't
+get propagated when setting the alarm time with RTC_WKALM_SET.
+
+Does something like my patch below look right ? We also don't handle
+alrm->pending, but I'm not sure if we have to.
+
+I tested this only very lightly since my current andy-tracking crashes
+in soc_suspend. If nobody else beats me to it, I'll have a look at it
+tomorrow.
+
+- Werner
+
+---------------------------------- cut here -----------------------------------
+
+According to Documentation/rtc.txt, RTC_WKALM_SET sets the alarm time
+and enables/disables the alarm. We implement RTC_WKALM_SET through
+pcf50633_rtc_set_alarm. The enabling/disabling part was missing.
+
+Signed-off-by: Werner Almesberger <werner@openmoko.org>
+Reported-by: Michael 'Mickey' Lauer <mickey@openmoko.org>
+---
+ drivers/rtc/rtc-pcf50633.c |    3 ++-
+ 1 files changed, 2 insertions(+), 1 deletions(-)
+
+diff --git a/drivers/rtc/rtc-pcf50633.c b/drivers/rtc/rtc-pcf50633.c
+index e1576d2..ddd6f89 100644
+--- a/drivers/rtc/rtc-pcf50633.c
++++ b/drivers/rtc/rtc-pcf50633.c
+@@ -221,8 +221,9 @@ static int pcf50633_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+ 	if (ret)
+ 		dev_err(dev, "Failed to write alarm time  %d\n", ret);
+ 
+-	if (!alarm_masked)
++	if (!alarm_masked || alrm->enabled)
+ 		pcf50633_irq_unmask(pcf, PCF50633_IRQ_ALARM);
++	pcf->rtc.alarm_enabled = alrm->enabled;
+ 
+ 	return 0;
+ }
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28/0004-manage-RTC-alarm-pending-flag-of-PCF50633.patch b/packages/linux/linux-openmoko-2.6.28/0004-manage-RTC-alarm-pending-flag-of-PCF50633.patch
new file mode 100644
index 0000000000..dadbd92941
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0004-manage-RTC-alarm-pending-flag-of-PCF50633.patch
@@ -0,0 +1,64 @@
+From 1fb682d2dfdaa19a50073fec6239f2bda9dbcc71 Mon Sep 17 00:00:00 2001
+From: Werner Almesberger <werner@openmoko.org>
+Date: Fri, 30 Jan 2009 14:37:40 +0000
+Subject: [PATCH 4/8] manage RTC alarm "pending" flag of PCF50633
+
+Backported to .28, original message below:
+
+This patch adds setting and clearing of the "pending" flag of the
+RTC alarm. The semantics follow the UEFI specification 2.2 available
+at http://www.uefi.org/specs/, i.e., the "pending" flag is cleared
+by disabling the alarm, but not by any other condition (such as the
+passing of time, a successful wakeup, or setting of a new alarm.)
+
+Signed-off-by: Werner Almesberger <werner@openmoko.org>
+---
+ drivers/rtc/rtc-pcf50633.c       |    5 +++++
+ include/linux/mfd/pcf50633/rtc.h |    1 +
+ 2 files changed, 6 insertions(+), 0 deletions(-)
+
+diff --git a/drivers/rtc/rtc-pcf50633.c b/drivers/rtc/rtc-pcf50633.c
+index ddd6f89..0fdadbd 100644
+--- a/drivers/rtc/rtc-pcf50633.c
++++ b/drivers/rtc/rtc-pcf50633.c
+@@ -185,6 +185,7 @@ static int pcf50633_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+ 	pcf = dev_get_drvdata(dev);
+ 
+ 	alrm->enabled = pcf->rtc.alarm_enabled;
++	alrm->pending = pcf->rtc.alarm_pending;
+ 
+ 	ret = pcf50633_read_block(pcf, PCF50633_REG_RTCSCA,
+ 				PCF50633_TI_EXTENT, &pcf_tm.time[0]);
+@@ -221,6 +222,9 @@ static int pcf50633_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
+ 	if (ret)
+ 		dev_err(dev, "Failed to write alarm time  %d\n", ret);
+ 
++	if (!alrm->enabled)
++		pcf->rtc.alarm_pending = 0;
++
+ 	if (!alarm_masked || alrm->enabled)
+ 		pcf50633_irq_unmask(pcf, PCF50633_IRQ_ALARM);
+ 	pcf->rtc.alarm_enabled = alrm->enabled;
+@@ -240,6 +244,7 @@ static void pcf50633_rtc_irq(struct pcf50633 *pcf, int irq, void *unused)
+ 	switch (irq) {
+ 	case PCF50633_IRQ_ALARM:
+ 		rtc_update_irq(pcf->rtc.rtc_dev, 1, RTC_AF | RTC_IRQF);
++		pcf->rtc.alarm_pending = 1;
+ 		break;
+ 	case PCF50633_IRQ_SECOND:
+ 		rtc_update_irq(pcf->rtc.rtc_dev, 1, RTC_PF | RTC_IRQF);
+diff --git a/include/linux/mfd/pcf50633/rtc.h b/include/linux/mfd/pcf50633/rtc.h
+index ce8ad8f..80cc6af 100644
+--- a/include/linux/mfd/pcf50633/rtc.h
++++ b/include/linux/mfd/pcf50633/rtc.h
+@@ -34,6 +34,7 @@
+ struct pcf50633_rtc {
+ 	int alarm_enabled;
+ 	int second_enabled;
++	int alarm_pending;
+ 
+ 	struct rtc_device *rtc_dev;
+ 	struct platform_device *pdev;
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28/0005-debug-glamo-allow-slower-memory-bus.patch.patch b/packages/linux/linux-openmoko-2.6.28/0005-debug-glamo-allow-slower-memory-bus.patch.patch
new file mode 100644
index 0000000000..39ae653fef
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0005-debug-glamo-allow-slower-memory-bus.patch.patch
@@ -0,0 +1,72 @@
+From 8c787f1c57c3b09beece662faabfab419ae5c8d6 Mon Sep 17 00:00:00 2001
+From: Andy Green <andy@openmoko.com>
+Date: Wed, 28 Jan 2009 09:58:59 +0000
+Subject: [PATCH 5/8] debug-glamo-allow-slower-memory-bus.patch
+
+Signed-off-by: Andy Green <andy@openmoko.com>
+---
+ drivers/mfd/glamo/glamo-core.c |   34 +++++++++++++++++++++++++++++++++-
+ 1 files changed, 33 insertions(+), 1 deletions(-)
+
+diff --git a/drivers/mfd/glamo/glamo-core.c b/drivers/mfd/glamo/glamo-core.c
+index b4595a8..e6253de 100644
+--- a/drivers/mfd/glamo/glamo-core.c
++++ b/drivers/mfd/glamo/glamo-core.c
+@@ -58,6 +58,25 @@
+ 
+ #define GLAMO_MEM_REFRESH_COUNT 0x100
+ 
++
++/*
++ * Glamo internal settings
++ *
++ * We run the memory interface from the faster PLLB on 2.6.28 kernels and
++ * above.  Couple of GTA02 users report trouble with memory bus when they
++ * upgraded from 2.6.24.  So this parameter allows reversion to 2.6.24
++ * scheme if their Glamo chip needs it.
++ *
++ * you can override the faster default on kernel commandline using
++ *
++ *   glamo3362.slow_memory=1
++ *
++ * for example
++ */
++
++static int slow_memory = 0;
++module_param(slow_memory, int, 0644);
++
+ struct reg_range {
+ 	int start;
+ 	int count;
+@@ -786,6 +805,19 @@ int glamo_run_script(struct glamo_core *glamo, struct glamo_script *script,
+ 			while ((__reg_read(glamo, GLAMO_REG_PLL_GEN5) & 3) != 3)
+ 				;
+ 			break;
++
++		/*
++		 * couple of people reported artefacts with 2.6.28 changes, this
++		 * allows reversion to 2.6.24 settings
++		 */
++
++		case 0x200:
++			if (slow_memory)
++				__reg_write(glamo, script[i].reg, 0xef0);
++			else
++				__reg_write(glamo, script[i].reg, 0xe03);
++			break;
++
+ 		default:
+ 			__reg_write(glamo, script[i].reg, script[i].val);
+ 			break;
+@@ -848,7 +880,7 @@ static struct glamo_script glamo_init_script[] = {
+ 	 * b7..b4 = 0 = no wait states on read or write
+ 	 * b0 = 1 select PLL2 for Host interface, b1 = enable it
+ 	 */
+-	{ 0x200,	0x0e03 },
++	{ 0x200,	0x0e03 /* this is replaced by script parser */ },
+ 	{ 0x202, 	0x07ff },
+ 	{ 0x212,	0x0000 },
+ 	{ 0x214,	0x4000 },
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28/0006-Subject-fix_glamo_xrandr_bug.patch.patch b/packages/linux/linux-openmoko-2.6.28/0006-Subject-fix_glamo_xrandr_bug.patch.patch
new file mode 100644
index 0000000000..b65e3513c2
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0006-Subject-fix_glamo_xrandr_bug.patch.patch
@@ -0,0 +1,46 @@
+From d0bc6c5baae3a711f5039ea5440bafb37ebdfc24 Mon Sep 17 00:00:00 2001
+From: Balaji Rao <balajirrao@openmoko.org>
+Date: Wed, 28 Jan 2009 19:30:45 +0000
+Subject: [PATCH 6/8] Subject: fix_glamo_xrandr_bug.patch
+
+fix_glamo_xrandr_bug.patch
+
+This patch reintroduces the 2-cycle delay used when accessing glamo-fb
+registers. This seems to be required even when the corresponding
+registers in HOST_BUS are off.
+
+Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
+---
+ drivers/mfd/glamo/glamo-fb.c |   10 ++++++++++
+ 1 files changed, 10 insertions(+), 0 deletions(-)
+
+diff --git a/drivers/mfd/glamo/glamo-fb.c b/drivers/mfd/glamo/glamo-fb.c
+index 64fe464..91cf75b 100644
+--- a/drivers/mfd/glamo/glamo-fb.c
++++ b/drivers/mfd/glamo/glamo-fb.c
+@@ -86,12 +86,22 @@ static struct platform_device glamo_spi_dev = {
+ static int reg_read(struct glamofb_handle *glamo,
+ 			   u_int16_t reg)
+ {
++	int i = 0;
++
++	for (i = 0; i != 2; i ++)
++		nop();
++
+ 	return readw(glamo->base + reg);
+ }
+ 
+ static void reg_write(struct glamofb_handle *glamo,
+ 			     u_int16_t reg, u_int16_t val)
+ {
++	int i = 0;
++
++	for (i = 0; i != 2; i ++)
++		nop();
++
+ 	writew(val, glamo->base + reg);
+ }
+ 
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28/0007-Subject-glamo_fix_improper_xrandr_geometry_setting.patch b/packages/linux/linux-openmoko-2.6.28/0007-Subject-glamo_fix_improper_xrandr_geometry_setting.patch
new file mode 100644
index 0000000000..0856e06020
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0007-Subject-glamo_fix_improper_xrandr_geometry_setting.patch
@@ -0,0 +1,216 @@
+From 3192193f8a1a799783963aaf10119b39c3e8df24 Mon Sep 17 00:00:00 2001
+From: Balaji Rao <balajirrao@openmoko.org>
+Date: Thu, 29 Jan 2009 18:25:32 +0000
+Subject: [PATCH 7/8] Subject: glamo_fix_improper_xrandr_geometry_setting.patch
+
+glamo_fix_improper_xrandr_geometry_setting.patch
+
+Switching to xrandr -o 3 from xrandr -o 1 caused the screen to look crazy
+because of the way lcd geometry is set in glamo. This patch fixes it.
+
+Signed-off-by: Balaji Rao <balajirrao@openmoko.org>
+---
+ drivers/mfd/glamo/glamo-fb.c |  109 ++++++++++++++++++-----------------------
+ 1 files changed, 48 insertions(+), 61 deletions(-)
+
+diff --git a/drivers/mfd/glamo/glamo-fb.c b/drivers/mfd/glamo/glamo-fb.c
+index 91cf75b..16531fa 100644
+--- a/drivers/mfd/glamo/glamo-fb.c
++++ b/drivers/mfd/glamo/glamo-fb.c
+@@ -75,6 +75,7 @@ struct glamofb_handle {
+ 	int cursor_on;
+ 	u_int32_t pseudo_pal[16];
+ 	spinlock_t lock_cmd;
++	int angle;	/* Current rotation angle */
+ };
+ 
+ /* 'sibling' spi device for lcm init */
+@@ -255,11 +256,6 @@ static void reg_set_bit_mask(struct glamofb_handle *glamo,
+ #define GLAMO_LCD_HV_RETR_DISP_START_MASK 0x03FF
+ #define GLAMO_LCD_HV_RETR_DISP_END_MASK 0x03FF
+ 
+-enum orientation {
+-    ORIENTATION_PORTRAIT,
+-    ORIENTATION_LANDSCAPE
+-};
+-
+ 
+ /* the caller has to enxure lock_cmd is held and we are in cmd mode */
+ static void __rotate_lcd(struct glamofb_handle *glamo, __u32 rotation)
+@@ -275,17 +271,22 @@ static void __rotate_lcd(struct glamofb_handle *glamo, __u32 rotation)
+ 	switch (rotation) {
+ 		case FB_ROTATE_UR:
+ 			glamo_rot = GLAMO_LCD_ROT_MODE_0;
++			glamo->angle = 0;
+ 			break;
+ 		case FB_ROTATE_CW:
+ 			glamo_rot = GLAMO_LCD_ROT_MODE_90;
++			glamo->angle = 90;
+ 			break;
+ 		case FB_ROTATE_UD:
+ 			glamo_rot = GLAMO_LCD_ROT_MODE_180;
++			glamo->angle = 180;
+ 			break;
+ 		case FB_ROTATE_CCW:
+ 			glamo_rot = GLAMO_LCD_ROT_MODE_270;
++			glamo->angle = 270;
+ 			break;
+ 		default:
++			glamo->angle = 0;
+ 			glamo_rot = GLAMO_LCD_ROT_MODE_0;
+ 			break;
+ 	}
+@@ -301,38 +302,12 @@ static void __rotate_lcd(struct glamofb_handle *glamo, __u32 rotation)
+ 				 GLAMO_LCD_MODE1_ROTATE_EN : 0);
+ }
+ 
+-static enum orientation get_orientation(struct fb_var_screeninfo *var)
+-{
+-	if (var->xres <= var->yres)
+-		return ORIENTATION_PORTRAIT;
+-
+-	return ORIENTATION_LANDSCAPE;
+-}
+-
+-static int will_orientation_change(struct fb_var_screeninfo *var)
+-{
+-	enum orientation orient = get_orientation(var);
+-
+-	switch (orient) {
+-		case ORIENTATION_LANDSCAPE:
+-			if (var->rotate == FB_ROTATE_UR ||
+-			    var->rotate == FB_ROTATE_UD)
+-				return 1;
+-			break;
+-		case ORIENTATION_PORTRAIT:
+-			if (var->rotate == FB_ROTATE_CW ||
+-			    var->rotate == FB_ROTATE_CCW)
+-				return 1;
+-			break;
+-	}
+-	return 0;
+-}
+-
+ static void glamofb_update_lcd_controller(struct glamofb_handle *glamo,
+ 					  struct fb_var_screeninfo *var)
+ {
+-	int sync, bp, disp, fp, total, xres, yres, pitch, orientation_changing;
++	int sync, bp, disp, fp, total, pitch;
+ 	unsigned long flags;
++	int width, height;
+ 
+ 	if (!glamo || !var)
+ 		return;
+@@ -355,31 +330,52 @@ static void glamofb_update_lcd_controller(struct glamofb_handle *glamo,
+ 				     GLAMO_ENGINE_LCD,
+ 				     var->pixclock);
+ 
+-	xres = var->xres;
+-	yres = var->yres;
++	if (glamo->angle == 90 || glamo->angle == 270) {
++		/* 
++		 * But if we are going back to portrait mode from here,
++		 * we get inverted values from Xglamo 
++		 */ 
++		if (!(var->rotate == FB_ROTATE_UR ||
++				var->rotate == FB_ROTATE_UD)) {
++			width = var->yres;
++			height = var->xres;
++		} else {
++			width = var->xres;
++			height = var->yres;
++		}
+ 
+-	/* figure out if orientation is going to change */
+-	orientation_changing = will_orientation_change(var);
++	} else {
++		width = var->xres;
++		height = var->yres;
++	}
+ 
+-	/* adjust the pitch according to new orientation to come */
++	/* Portrait ? */
++	if (var->rotate == FB_ROTATE_UR || var->rotate == FB_ROTATE_UD) {
++		/* We don't need to set xres and yres in this particular case
++		 * because Xglamo does it for us */
++		if (!(glamo->angle == 90 || glamo->angle == 270)) {
++			var->xres = width;var->yres = height;
++		}
+ 
+-	if (orientation_changing) {
+-		pitch = var->yres * var->bits_per_pixel / 8;
+-        } else {
+-		pitch = var->xres * var->bits_per_pixel / 8;
+-        }
++		var->xres_virtual = width * 2;
++		var->yres_virtual = height;
++		pitch = width * var->bits_per_pixel / 8;
++	} else {
++		var->xres = height;
++		var->yres = width;
++		var->xres_virtual = height;
++		var->yres_virtual = width * 2;
++		pitch = height * var->bits_per_pixel / 8;
++	}
+ 
+-	/*
+-	 * set the desired LCD geometry
+-	 */
+ 	reg_set_bit_mask(glamo,
+ 			 GLAMO_REG_LCD_WIDTH,
+ 			 GLAMO_LCD_WIDTH_MASK,
+-			 xres);
++			 width);
+ 	reg_set_bit_mask(glamo,
+ 			 GLAMO_REG_LCD_HEIGHT,
+ 			 GLAMO_LCD_HEIGHT_MASK,
+-			 yres);
++			 height);
+ 	reg_set_bit_mask(glamo,
+ 			 GLAMO_REG_LCD_PITCH,
+ 			 GLAMO_LCD_PITCH_MASK,
+@@ -388,22 +384,11 @@ static void glamofb_update_lcd_controller(struct glamofb_handle *glamo,
+ 	/* honour the rotation request */
+ 	__rotate_lcd(glamo, var->rotate);
+ 
+-	/* update the reported geometry of the framebuffer. */
+-	if (orientation_changing) {
+-		var->xres_virtual = var->xres = yres;
+-		var->xres_virtual *= 2;
+-		var->yres_virtual = var->yres = xres;
+-	} else {
+-		var->xres_virtual = var->xres = xres;
+-		var->yres_virtual = var->yres = yres;
+-		var->yres_virtual *= 2;
+-	}
+-
+ 	/* update scannout timings */
+ 	sync = 0;
+ 	bp = sync + var->hsync_len;
+ 	disp = bp + var->left_margin;
+-	fp = disp + xres;
++	fp = disp + width;
+ 	total = fp + var->right_margin;
+ 
+ 	reg_set_bit_mask(glamo, GLAMO_REG_LCD_HORIZ_TOTAL,
+@@ -420,7 +405,7 @@ static void glamofb_update_lcd_controller(struct glamofb_handle *glamo,
+ 	sync = 0;
+ 	bp = sync + var->vsync_len;
+ 	disp = bp + var->upper_margin;
+-	fp = disp + yres;
++	fp = disp + height;
+ 	total = fp + var->lower_margin;
+ 
+ 	reg_set_bit_mask(glamo, GLAMO_REG_LCD_VERT_TOTAL,
+@@ -836,6 +821,8 @@ static int __init glamofb_probe(struct platform_device *pdev)
+ 	glamofb->fb = fbinfo;
+ 	glamofb->dev = &pdev->dev;
+ 
++	glamofb->angle = 0;
++
+ 	strcpy(fbinfo->fix.id, "SMedia Glamo");
+ 
+ 	glamofb->reg = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28/0008-Send-pen-up-events-faster-side-effect-improve-illu.patch b/packages/linux/linux-openmoko-2.6.28/0008-Send-pen-up-events-faster-side-effect-improve-illu.patch
new file mode 100644
index 0000000000..5960ad0c37
--- /dev/null
+++ b/packages/linux/linux-openmoko-2.6.28/0008-Send-pen-up-events-faster-side-effect-improve-illu.patch
@@ -0,0 +1,41 @@
+From 5e50f877f7ef2309a5318fc6ceed4903d1d80a64 Mon Sep 17 00:00:00 2001
+From: Nelson Castillo <arhuaco@freaks-unidos.net>
+Date: Thu, 29 Jan 2009 14:27:25 +0000
+Subject: [PATCH 8/8] Send pen-up events faster (side effect: improve illume keyboard responsiveness)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: 8bit
+
+We were waiting 60ms before reporting a pen-up event to avoid
+jitter. Now we wait 8ms (actually 5 with HZ == 200).
+
+Thanks to Marco Trevisan for testing and pointing out that there was a
+problem that could be spotted with the illume keyboard.
+Note that I used the Terminal mode of the keyboard (no dictionary)
+for tests.
+
+I also used touch_test.py and the jitter doesn't seem to be an
+issue when drawing lines with the finger.
+
+Reported-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
+Signed-off-by: Nelson Castillo <arhuaco@freaks-unidos.net>
+---
+ drivers/input/touchscreen/s3c2410_ts.c |    2 +-
+ 1 files changed, 1 insertions(+), 1 deletions(-)
+
+diff --git a/drivers/input/touchscreen/s3c2410_ts.c b/drivers/input/touchscreen/s3c2410_ts.c
+index bc9b410..a37adc9 100644
+--- a/drivers/input/touchscreen/s3c2410_ts.c
++++ b/drivers/input/touchscreen/s3c2410_ts.c
+@@ -96,7 +96,7 @@ MODULE_LICENSE("GPL");
+ 
+ static char *s3c2410ts_name = "s3c2410 TouchScreen";
+ 
+-#define TS_RELEASE_TIMEOUT (HZ >> 4)		/* ~ 60 milliseconds */
++#define TS_RELEASE_TIMEOUT (HZ >> 7 ? HZ >> 7 : 1) /* 8ms (5ms if HZ is 200) */
+ #define TS_EVENT_FIFO_SIZE (2 << 6) /* must be a power of 2 */
+ 
+ #define TS_STATE_STANDBY 0 /* initial state */
+-- 
+1.5.2.2
+
diff --git a/packages/linux/linux-openmoko-2.6.28_git.bb b/packages/linux/linux-openmoko-2.6.28_git.bb
index e37742caa2..8774721308 100644
--- a/packages/linux/linux-openmoko-2.6.28_git.bb
+++ b/packages/linux/linux-openmoko-2.6.28_git.bb
@@ -8,11 +8,19 @@ KERNEL_VERSION = "${KERNEL_RELEASE}"
 
 OEV = "oe1"
 PV = "${KERNEL_RELEASE}-${OEV}+gitr${SRCREV}"
-PR = "r2"
+PR = "r3"
 
 SRC_URI = "\
   git://git.openmoko.org/git/kernel.git;protocol=git;branch=andy-tracking \
   file://openwrt-ledtrig-netdev.patch;patch=1 \
+  file://0001-MERGE-via-pending-tracking-hist-subject-usb-gadget-r.patch;patch=1 \
+  file://0002-MERGE-via-pending-tracking-hist-subject-usb-gadget-f.patch;patch=1 \
+  file://0003-consider-alrm-enable-in-pcf50633_rtc_set_alarm.patch;patch=1 \
+  file://0004-manage-RTC-alarm-pending-flag-of-PCF50633.patch;patch=1 \
+  file://0005-debug-glamo-allow-slower-memory-bus.patch.patch;patch=1 \
+  file://0006-Subject-fix_glamo_xrandr_bug.patch.patch;patch=1 \
+  file://0007-Subject-glamo_fix_improper_xrandr_geometry_setting.patch;patch=1 \
+  file://0008-Send-pen-up-events-faster-side-effect-improve-illu.patch;patch=1 \
   file://defconfig-oe.patch \
 "
 S = "${WORKDIR}/git"