diff options
Diffstat (limited to 'packages/linux/linux-openmoko-2.6.28')
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 + |