summaryrefslogtreecommitdiff
path: root/packages/linux/linux-openmoko-2.6.28
diff options
context:
space:
mode:
Diffstat (limited to 'packages/linux/linux-openmoko-2.6.28')
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0001-MERGE-via-pending-tracking-hist-subject-usb-gadget-r.patch55
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0002-MERGE-via-pending-tracking-hist-subject-usb-gadget-f.patch50
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0003-consider-alrm-enable-in-pcf50633_rtc_set_alarm.patch52
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0004-manage-RTC-alarm-pending-flag-of-PCF50633.patch64
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0005-debug-glamo-allow-slower-memory-bus.patch.patch72
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0006-Subject-fix_glamo_xrandr_bug.patch.patch46
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0007-Subject-glamo_fix_improper_xrandr_geometry_setting.patch216
-rw-r--r--packages/linux/linux-openmoko-2.6.28/0008-Send-pen-up-events-faster-side-effect-improve-illu.patch41
8 files changed, 596 insertions, 0 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
+