aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2008-11-19Re: [PATCH]: Cleanup of leds-neo1973Nelson Castillo
Remove unneeded spaces and coding style fixes. Purely cosmetic.
2008-11-19fix-stable-tracking-build-without-symlink.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19[ARM]: Move asm/arch/gpio.h to mach/ directoryJonas Bonn
This file was moved in the big file move, but some OpenMoko specific changes did not make it. This patch peels out the relevant bits and adds them to the gpio.h file in the upstream location. The only OpenMoko specific change is the definition of gpio_to_irq and irq_to_gpio. These functions should really be defined in gpio_chip and asm-generic/gpio.h; this is coming soon, but until then we'll just use the Moko definitions that we've been using up until now. This is not strictly correct for the GTA02 case, but it works given the configuration that's currently in use. This can be fixed (and should become evident) when the configuration options are cleaned up. Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
2008-11-19[ARM]: Move asm/arch/gta01.h to include/machJonas Bonn
This file is OpenMoko specific and didn't get moved in the big file move. Move it to arch/arm/mach-s3c2410/include/mach where it belongs and fix the references to it. Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
2008-11-19[ARM]: Build fix after file moveJonas Bonn
After the big include file move these paths ended up incorrect. Fix these so that this builds cleanly again. Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
2008-11-19suppress "onkey" events on resume [Was: Re: Where are actions configured for ↵\\\\\\\\\\\\\\\"Mike (mwester)\\\\\\\\\\\\
buttons in FSO?] Michael 'Mickey' Lauer wrote: ... > The problem is (and this is the reason why I'm crossposting this to the > kernel mailing list), the kernel is not swallowing the power button > presses that triggers the resume, so you need some "real" programming > (as opposed to the expressional complexity of our rules) in order to > prevent falling asleep right after resume. > > Kernel-guys, can we change that? suppress-resume-onkey-event.patch This suppresses the key press and key release events from the power button, in the case where the power button is the wake event for the GTA01 or GTA02 device. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19fix-wrongful-led-trigger-removal.patchSean McNeil
LED trigger gets removed in led_brightness_store??? Signed-off-by: Sean McNeil <sean@mcneil.com>
2008-11-19fix-lis302dl-issues.patchSean McNeil
Move to level from edge, fix local_save... to local_irq... simplify bitbang sequence Signed-off-by: Sean McNeil <sean@mcneil.com>
2008-11-19clean-leds-remove-pwm-stuff.patchSean McNeil
Remove unsued PWM stuff around LEDs. Signed-off-by: Sean McNeil <sean@mcneil.com>
2008-11-19add-powersupply-ac-usb-automonitor.patchSean McNeil
Adds AC and USB powersupply objects, and a workqueue to automonitor changes in battery state and fire change events on any change to selected registers. Signed-off-by: Sean McNeil <sean@mcneil.com>
2008-11-19add-neo1973kbd-jack-state-sys.patchSean McNeil
Add /sys files for jack state reporting. Signed-off-by: Sean McNeil <sean@mcneil.com>
2008-11-19glamo_fb: Implement screen blankingHarald Welte
This patch implements fb_blank() for the glamo-fb driver, which switches off the pixel clock (DCLK) for power saving. We currently delay the actual pixel clock switch until we enter FB_BLANK_POWERDOWN, since the backlight fade is slow and we don't want the user to see artefacts on the screen while the backlight is fading out. So since the X server first sends FB_BLANK_{V,H}SYNC_SUSPEND, we start the backlight fade here, and only once we get FB_BLANK_POWERDOWN the pixel clock is disabled. There are no measurements yet, but the power savings should be double, since there is no longer any generation of the high-frequency LCM signals, and there are no video-related SDRAM accesses anymore. Signed-off-by: Harald Welte <laforge@openmoko.org>
2008-11-19glamo_fb: sync comment with codeHarald Welte
the comment claims that DHCLK is enabled, while the code actually disables it. No code change, purely cosmetic patch. Signed-off-by: Harald Welte <laforge@openmoko.org>
2008-11-19glamo_fb: Cosmetic cleanupHarald Welte
Remove dead code and coding style fixes. Purely cosmetic. Signed-off-by: Harald Welte <laforge@openmoko.org>
2008-11-19fix-pcf50633-do-backlight-bringup-in-probe.patchAndy Green
Qi does not touch the backlight, we have to do it in Linux now Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19This patch adds a framebuffer notifier in order to detectHarald Welte
FB_BLANK events and switch the JBT6K74 LCM controller into its power saving mode. This has the potential of saving something like 50mW during screen blank. Signed-off-by: Harald Welte <laforge@openmoko.org>
2008-11-19revert-fix-build-with-no-config_mmc-glamo-resume-callback-part.patchAndy Green
Thomas White noticed that the recent patch from Andrzej cleaning up a nasty cast in the resume_dependency stuff for Glamo broke resume. The problem was that the wrong resume callback was arrived at by the new code, the one in the device's device_driver struct rather than the struct platform_driver that actually holds the right pointer. Since this code will be gone in 2.6.26, I reverted this part of Andrzej's patch, tidying the cast a bit anyway. Reported-by: Thomas White <taw27@cam.ac.uk> Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc9-hdq-ordering.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19GTA01: replace mutex with spinlock in neo1973_vib_vib_setJonas Bonn
This function (set_brightness) may be called in interrupt context and therefore should not sleep; use a spin_lock instead of a mutex to ensure this. This should take care of the following BUG: [21474678.340000] BUG: sleeping function called from invalid context at kernel/mutex.c:207 [21474678.340000] in_atomic():1, irqs_disabled():0 [21474678.340000] no locks held by python/1255. [21474678.340000] [<c002d928>] (dump_stack+0x0/0x18) from [<c003b08c>] (__might_sleep+0xdc/0xf8) [21474678.340000] [<c003afb0>] (__might_sleep+0x0/0xf8) from [<c02efc08>] (mutex_lock_nested+0x2c/0x264) [21474678.340000] r5:c03ed754 r4:c03ed6dc [21474678.340000] [<c02efbdc>] (mutex_lock_nested+0x0/0x264) from [<c022e180>] (neo1973_vib_vib_set+0x2c/0x6c) [21474678.340000] [<c022e154>] (neo1973_vib_vib_set+0x0/0x6c) from [<c022e6a4>] (led_timer_function+0x8c/0xb4) [21474678.340000] r6:c041a1a0 r5:c7f34820 r4:0000012c [21474678.340000] [<c022e618>] (led_timer_function+0x0/0xb4) from [<c004aeb4>] (run_timer_softirq+0x180/0x20c) [21474678.340000] r5:c7f3482c r4:00000102 [21474678.340000] [<c004ad34>] (run_timer_softirq+0x0/0x20c) from [<c0046368>] (__do_softirq+0x64/0xd8) [21474678.340000] r8:00000000 r7:00000001 r6:0000000a r5:c0419ff8 r4:00000041 [21474678.340000] [<c0046304>] (__do_softirq+0x0/0xd8) from [<c0046764>] (irq_exit+0x48/0x5c) [21474678.340000] r6:00000000 r5:c03d128c r4:0000001e [21474678.340000] [<c004671c>] (irq_exit+0x0/0x5c) from [<c0028050>] (__exception_text_start+0x50/0x68) [21474678.340000] [<c0028000>] (__exception_text_start+0x0/0x68) from [<c0028a8c>] (__irq_usr+0x4c/0xe0) [21474678.340000] Exception stack(0xc7d7bfb0 to 0xc7d7bff8) [21474678.340000] bfa0: 0055bb3a 0000004a 00000000 0055baf0 [21474678.340000] bfc0: 0000004a 0052ae30 00000025 005168e0 00000073 00000025 401281ec 00000000 [21474678.340000] bfe0: 0000006f be9b8470 006e0069 400a8844 60000010 ffffffff [21474678.340000] r6:00004000 r5:f4000000 r4:ffffffff Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
2008-11-19Drop FIQ dependency for GTA01 configuration.Jonas Bonn
When the config option MACH_NEO1973_GTA02 is not set, then we do not need to have any access to the FIQ symbols. Signed-off-by: Jonas Bonn <jonas.bonn@gmail.com>
2008-11-19always-call-resume-dependencies.patch\\\\\\\\\\\\\\\"Mike (mwester)\\\\\\\\\\\\
Attached is a patch that has greatly reduced the frequency of failures to resume (due to an oops from the glamo resume handler), and the dreaded "white screen after resume". I can't say that it fixes all of these, although I have yet to see the white-screen since applying this patch and suspending/resuming several hundred times (with the 30-second suspend on the 2008.8 image and the endless stream of GSM error messages generated by something in that image, it has proved to be very useful to do an automated stress test!) This patch will apply to stable, and should make stable slightly more, well, "stable". [Feel free to remove the debug messages if someone feels strongly about that; I left them in because I think they might be useful in triaging further crashes; I'm not at all convinced that this patch will fix all the cases of resume failures.] [[And, yes, this is ugly, really ugly.]] [[[Oh yeah - there's still one extreme case that will result in an oops: if a dependent driver is built as a module, and it is unloaded, and it happened that the preceding suspend/resume was aborted, and that abort happened between the dependent driver and the driver upon which it is dependent, then a list entry will be left behind referencing the unloaded module. There's just no good way to fix that given the way the resume dependency plumbing is connected up right now, so just avoid using modules for any of the drivers involved in the resume dependency stuff.]]] Regards, Mike (mwester) commit 905d2fc9c45f622418ce9ef4e67c23453aab7571 Author: Mike Westerhof <mwester@dls.net> Date: Mon Aug 11 11:11:25 2008 -0500 always-call-resume-dependencies.patch Ensure that a dependent resume handler is always executed, even if the resume handler for driver upon which it is dependent never suspends (and therefore never resumes either). Also make sure that we do not end up with duplicate dependencies registered, something that can happen if the suspend is aborted due to driver failure or an early resume (such as occurs when the GSM interrupts during suspend). Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19fix-build-with-no-CONFIG_MMCAndrzej Zaborowski
I hit this when updating to 2.6.26. Also if CONFIG_MMC is enabled this patch converts this horrible horrible hack into a horrible hack by using dev->resume() (untested). Signed-off-by: Andrzej Zaborowski <balrog@zabor.org>
2008-11-19fix-glamo-mci-slow-clock-until-first-bulk.patchAndy Green
This patch adds another module parameter to glamo-mci which sets the SD Card clock rate used inbetween powering the card and the completion of the first bulk transfer. You can set it from kernel commandline like this. glamo_mci.sd_post_power_clock=1000000 The period between changing the power state and the first bulk transfer completion is critical because larger SDHC cards take longer to initialize before they can service the bulk transfer, and the Glamo MMC unit has a fixed timeout length of a maximum of 4095 x 16 x SD Card clocks. Large cards like 8GB Sandisk SDHC are not ready before this timeout is used up at default 16MHz. Subsequently, the card can handle 16MHz SD Clock and timeout durations okay. By default this patch operates the SD Clock at only 1MHz until the first bulk transfer is completed after each powerup action from the MCI stack. It also keeps the SD Clock running during this time, and disables the SD Clock if the card is not present and the MCI stack removes power. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19Make-s3c2410-gadget-initialize-with-no-debugfsAndrzej Zaborowski
I needed the following two changes for g_ether to work with last week's stable-tracking and no CONFIG_DEBUG_FS. I don't know if they're related to moko patches, if not I can send them upstream isntead. BTW I need to boot off the SD card now because mtd only returns CRC errors and doesn't mount. Does it work for other people? Signed-off-by: Andrzej Zaborowski <balrog@zabor.org>
2008-11-19gta03-pca9632.patchMatt Hsu
- pca9632 is a LED driver which will be adopted in gta03. Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
2008-11-19Subject: [PATCH] rework-to-make-USBINS-USBREM-exclusive.patchMatt Hsu
This patch is a work-around solution to correct charging indication logic. Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
2008-11-19ar6k-essid-one-and-32.patchWerner Almesberger
This patch allows ESSID with length 1, which were rejected because the stack assumed iwconfig used a different format in the ioctl's payload. It also refuses ESSIDs longer than 31 bytes, because there is some buffer overrun issue buried somewhere else in the stack. In principle, 32 bytes should be fine. Open issue: - where is the 32 bytes overrun ? Signed-off-by: Werner Almesberger <werner@openmoko.org>
2008-11-19newline_after_disconnect_msg.patchmattb
This is purely cosmetic, but annoying. The ar6k wifi driver does not print a newline after the informational message when disconnecting from an AP. This leads to cluttered dmesg output like the following: AR6000 disconnected from 00:02:cf:85:c6:08 AR6000 connected event on freq 2412 with bssid 00:02:cf:85:c6:08 listenInterval=100, beaconInterval = 100, beaconIeLen = 0 assocReqLen=27 assocRespLen =22 What is expected, is something like: AR6000 disconnected from 00:02:cf:85:c6:08 AR6000 connected event on freq 2412 with bssid 00:02:cf:85:c6:08 listenInterval=100, beaconInterval = 100, beaconIeLen = 0 assocReqLen=27 assocRespLen =22 The upside of this is that it gives me a nice simple patch to send in as my first contribution to OpenMoko?. Cheers Signed-off-by: mattb <mattb@openmoko-trac.invalid>
2008-11-19soft_tap.patchDima Kogan
Hi all. I'm seeing a behavior in my freerunner where light taps on the touchscreen are not registered as clicks by the kernel even though the base hardware does report clicking events. I'm seeing the kernel generate extra "unclick" events in these cases. It looks like in the driver, an unclick event is processed before the click event, thus suppressing the click from ever being generated. I'm attaching a patch that addresses this. I'm now able to type much faster on the matchbox keyboard, even when using my fingertips instead of fingernails. Dima Signed-off-by: Dima Kogan <dkogan@cds.caltech.edu>
2008-11-19fix-glamo-idleclock-around-suspend.patchAndy Green
Possible implementation of SD Card corruption workaround reported here https://docs.openmoko.org/trac/ticket/1802#comment:5 Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-one-mmc-race.patchAndy Green
Some boots from Qi trigger a symptom from this interesting race --> [ 2.730000] Unable to handle kernel NULL pointer dereference at virtual address 00000248 [ 2.730000] pgd = c0004000 [ 2.735000] [00000248] *pgd=00000000 [ 2.735000] Internal error: Oops: 5 [#1] PREEMPT [ 2.735000] Modules linked in: [ 2.735000] CPU: 0 Not tainted (2.6.24-stable10_0c1587137aaf0ee3-mokodev #1071) [ 2.735000] PC is at pcf50633_voltage_set+0x1c/0xfc [ 2.735000] LR is at gta02_glamo_mmc_set_power+0xdc/0x128 [ 2.735000] pc : [<c01df570>] lr : [<c0034324>] psr: 60000013 [ 2.735000] sp : c7c57eb0 ip : c7c57ec8 fp : c7c57ec4 [ 2.735000] r10: c7cfca28 r9 : 00000000 r8 : c7c57f68 [ 2.735000] r7 : c7cfca68 r6 : c7cfcae0 r5 : 00000c80 r4 : 00000000 [ 2.735000] r3 : 00000000 r2 : 00000c80 r1 : 0000000a r0 : 00000c80 [ 2.735000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.735000] Control: c000717f Table: 30004000 DAC: 00000017 [ 2.735000] Process kmmcd (pid: 102, stack limit = 0xc7c56268) [ 2.735000] Stack: (0xc7c57eb0 to 0xc7c58000) [ 2.735000] 7ea0: c0608c58 00000c80 c7c57edc c7c57ec8 [ 2.735000] 7ec0: c0034324 c01df564 c7cfca28 c7cfc800 c7c57f1c c7c57ee0 c0194de0 c0034258 [ 2.735000] 7ee0: c7c57f34 c7c57ef0 c01e6230 c005de5c 60000013 c7cfca28 c7cfc800 60000013 [ 2.735000] 7f00: c7cfca68 c7c57f68 00000000 c01e6778 c7c57f34 c7c57f20 c01e5d68 c0194da8 [ 2.735000] 7f20: c7cfc800 c7cfca08 c7c57f5c c7c57f38 c01e6810 c01e5cbc c0059278 c7c57f48 [ 2.735000] 7f40: c02d2ba0 00000002 c7c44420 c7c56000 c7c57f9c c7c57f60 c00592e0 c01e6788 [ 2.735000] 7f60: 00000002 c0059278 c0608d74 c04321cc c036e16c 00000000 c7c57fb0 c7c44420 [ 2.735000] 7f80: c7c56000 00000000 00000000 00000000 c7c57fd4 c7c57fa0 c005a068 c00591ec [ 2.735000] 7fa0: c02d0624 00000000 c7c4c0e0 c005dc2c c7c57fb0 c7c57fb0 00000000 c7c56000 [ 2.735000] 7fc0: c7c44420 c0059f84 c7c57ff4 c7c57fd8 c005db28 c0059f94 00000000 00000000 [ 2.735000] 7fe0: 00000000 00000000 00000000 c7c57ff8 c004b170 c005dad8 ffffffff ffffffff [ 2.735000] Backtrace: [ 2.735000] [<c01df554>] (pcf50633_voltage_set+0x0/0xfc) from [<c0034324>] (gta02_glamo_mmc_set_power+0xdc/0x128) [ 2.735000] r5:00000c80 r4:c0608c58 [ 2.735000] [<c0034248>] (gta02_glamo_mmc_set_power+0x0/0x128) from [<c0194de0>] (glamo_mci_set_ios+0x48/0x254) [ 2.735000] r5:c7cfc800 r4:c7cfca28 [ 2.735000] [<c0194d98>] (glamo_mci_set_ios+0x0/0x254) from [<c01e5d68>] (mmc_power_up+0xbc/0x100) [ 2.735000] [<c01e5cac>] (mmc_power_up+0x0/0x100) from [<c01e6810>] (mmc_rescan+0x98/0x1a8) [ 2.735000] r5:c7cfca08 r4:c7cfc800 [ 2.735000] [<c01e6778>] (mmc_rescan+0x0/0x1a8) from [<c00592e0>] (run_workqueue+0x104/0x208) [ 2.735000] r6:c7c56000 r5:c7c44420 r4:00000002 [ 2.735000] [<c00591dc>] (run_workqueue+0x0/0x208) from [<c005a068>] (worker_thread+0xe4/0xf8) [ 2.735000] [<c0059f84>] (worker_thread+0x0/0xf8) from [<c005db28>] (kthread+0x60/0x94) [ 2.735000] r6:c0059f84 r5:c7c44420 r4:c7c56000 [ 2.735000] [<c005dac8>] (kthread+0x0/0x94) from [<c004b170>] (do_exit+0x0/0x6f4) [ 2.735000] r6:00000000 r5:00000000 r4:00000000 [ 2.735000] Code: e351000a e1a04000 e1a00002 8a000032 (e5943248) [ 2.745000] ---[ end trace 123ec1d286354824 ]--- This problem was caused by insufficient timeout waiting for pcf50633 to resume and broken code to detect timeout exhaustion. Although I'd like to think it has something to do with mmc resume woes it should make a panic and subsequent emergency spew on UART2 if that had been the case. Took the opportunity to move the stuff to show completion of probe to later in the pcf50633 probe and tighten readiness test. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19gta02-accel-isr-fix-more.patchAndy Green
Fix all of the mismatches Andrzej put us on to. Found-by: Andrzej Zaborowski <balrogg@gmail.com> Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19checkpatch-accel-fixes.patchAndy Green
style cleanups for accel threshold setting patch Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19interface for configuring freefall/wakeup interrupts for the accelerometersSimon Kagstrom
Hi! First: Unfortunately, the freerunner currently wakes up immediately on suspend when the accelerometer IRQ is selected as a wakeup source. I'm posting this for comments and if someone else wants to have a look at this problem. The patch should be safe to apply even though the sleep portion doesn't work - as long as it's configured it will not disturb anything. // Simon -- lis302dl-configure-wakeup-interrupts.patch From: simon.kagstrom <simon.kagstrom@gmail.com> First: Unfortunately, the freerunner currently wakes up immediately on suspend when the accelerometer IRQ is selected as a wakeup source. Add configuration of wakeup/freefall interrupts through a sysfs interface. Configuration is done through echoing a value of the form X Y Z THRESHOLD DURATION SPEC to freefall_wakeup_1/2. X, Y and Z are threshold values, given as a value > 0, < 0 or 0 to specify if an interrupt should be generated for high or low thresholds or neither (off). THRESHOLD specifies the threshold that must be exceeded. DURATION specifies the time in milliseconds for which the acceleration should be measured. SPEC is either '1' or '0' and specifies if the thresholds should be taken all together or one at a time ('and' or 'or' mode). Echoing '0' to the file turns off the interrupts. Example: echo "1 1 1 60 60 0" > freefall_wakeup_1 # Turn on x,y,z, 60ms/60 threshold, or-mode echo "0" > freefall_wakeup_1 # Turn off interrupt The hardware supports two simulataneous wakeup sources to be configured, but the freerunner only connects one of the interrupt outputs. The patch exports both. Similarly, only the "top" accelerometer can be used as a wake-up source, and it's not possible to generate DATA_READY interrupts while the wakeup interrupts are active. Signed-off-by: Simon Kagstrom <simon.kagstrom@gmail.com>
2008-11-19From 5ee1ee9e1c8a652b0f9cde72ad5e547db87d4d67 Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [gta02] Disable hardware ECC unless we get instructed to enable it This is restoring the old behavior in regard to ECC. Even if hardware ECC was compiled in we didn't use it. Make this a runtime option. If the bootloader passes hardware_ecc we will enable the hardware ECC for real.
2008-11-19From 98d97ee93af676f7d6d0bf55aaae17e11304598a Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] Revert "s3c2440-nand-disable-hwecc.patch" This reverts commit 1d89da736ed33d3f7c398fb9f8dfddecb7c7c7a9.
2008-11-19lis302dl-allow-unloading-module.patchSimon Kagstrom
This patch fixes module unloading for the accelerometer (actually module loading failed before). The two problems were that the interrupt was not unregistered, and that the device was left in a "strange" state. Signed-off-by: Simon Kagstrom <simon.kagstrom@gmail.com>
2008-11-19tracking-2.6.27-rc2-fix-fiq.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19add-s3c-serial-total-meddlings.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19revert-drivers-serial-s3c2410.c-meddlings.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc2-include-path-changes.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-no-discharging.patchAndy Green
We failed to report status of "discharging", instead reporting "not charging" even if we knew that the charger was not present. This patch corrects it and reports "discharging" when charger is absent. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19checkpatch-fixes.patchAndy Green
This cleans out some random externs in C files that checkpatch does not like and introduces a couple of .h files to contain them. Plus some other minor checkpatch style complaints. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-suspend-backlight-timing-gta01.patchMike Westerhof
This patch adds the gta01 backlight callback that defers the restoring of the backlight until after the jbt driver has resumed. This doesn't eliminate the flashing of the LCD on the gta01, but it reduces it considerably. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19gta01-pcf50606-disable-irq-from-suspend-until-resume.patchMike Westerhof
This patch is the pcf50606 equivalent of the pcf50633 patch that disables interrupts from the chip until after resume is complete. In order to ensure no data is lost, the work function is called post-resume to process any pending interrupts. Most of the code was quite literally re-used from Andy Green's original patch. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19silence-serial-console-gta01.patchMike Westerhof
This patch ensures that no console data will go the UART while the GSM mux is switched to the GSM. This is necessary despite the code that disables the console due to the fact that the console resumes before the neo1973_pm_gsm driver, and consoles always resume in the "on" state. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19commit 830ea3d0c27c0c750b7bf1b56c002ee7943f3edcMike Westerhof
gta0x-log-serial-rx-error.patch This patch causes a KERN_DEBUG message to be printed each time an error status is read from a UART. This is intended to facilitate the reporting of more useful problem and bug reports from users in the field. Signed-off-by: Mike Westerhof <mwester@dls.net>
2008-11-19From fa269b44512a03523b164c3cebc20312748c524b Mon Sep 17 00:00:00 2001Holger Freyther
Subject: [PATCH] [ar6k] Build the wireless driver without DEBUG - Remove DEBUG from the Makefile - Do not send events through netlink to userspace. We might need to reevaluate this. But we seem to use wireless_send_event at the right places. (SEND_EVENT_TO_APP) - Do not report debug logs to apps (REPORT_DEBUG_LOGS_TO_APP) Signed-Off-By: Holger Freyther <zecke@openmoko.org>
2008-11-19fix-pcf50633-usbrem-charging-led.patchAndy Green
If the charger was removed, we fell through back to old hdq-driven code with normally wrong but slightly random results for charging LED behaviour in that circumstance This patch makes us use the tracked charger status callbacks alone if they are defined in the platform data. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-crank-memory-to-90MHz.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>