aboutsummaryrefslogtreecommitdiff
path: root/drivers/mfd/glamo/glamo-core.c
AgeCommit message (Collapse)Author
2009-01-22MERGE-via-pending-tracking-hist-MERGE-via-stable-tracking-MERGE-via-mokopatc ↵merge
hes-tracking-fix-stray-endmenu-patch-1232632040-1232632141 pending-tracking-hist top was MERGE-via-stable-tracking-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040-1232632141 / fdf777a63bcb59e0dfd78bfe2c6242e01f6d4eb9 ... parent commitmessage: From: merge <null@invalid> MERGE-via-stable-tracking-hist-MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040 stable-tracking-hist top was MERGE-via-mokopatches-tracking-fix-stray-endmenu-patch-1232632040 / 90463bfd2d5a3c8b52f6e6d71024a00e052b0ced ... parent commitmessage: From: merge <null@invalid> MERGE-via-mokopatches-tracking-hist-fix-stray-endmenu-patch mokopatches-tracking-hist top was fix-stray-endmenu-patch / 3630e0be570de8057e7f8d2fe501ed353cdf34e6 ... parent commitmessage: From: Andy Green <andy@openmoko.com> fix-stray-endmenu.patch Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-20glamo_mci_use_regulator_api.patchBalaji Rao
Changes the glamo-mci driver to use the regulator API.
2008-11-19fix-glamo-gpio-resume.patchAndy Green
Glamo GPIO are not set correctly after resume / reset action. This patch forces them to correct state for GTA02. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19meddle-wsod.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-suspend-remove-reg-dump-and-restore.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-resume-dont-restuff-regs-do-reinit-in-framebuffer-resume.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-glamo-suspend-even-more-meddling.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-rebase-dust.patchAndy Green
Last rebase to stable-2.6.26 left some trash from rebasing the patches on top of this, clean it back out Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19debug-glamo-syslog-dumps.patchAndy Green
More effort to refine power code that does the suspend and resume actions Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19debug-resume-hang.patchAndy Green
Weeks of frantic effort to control Glamo, traced the issue to two outcomes: nWAIT is forced down and the device is hard locked, or we survive immediate Glamo resume and die again with nWAIT forced down when the framebuffer driver tries to flash the soft cursor. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19glamo-resume-meddling.patchAndy Green
Big chunk of trying to own Glamo resume and not really succeeding Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-remove-resume-dependencies-on-pmu-for-pmu-children.patchAndy Green
All that stuff should be enforced by device tree now, out with it Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-suspend-cant-use-pll-host-bus-clock-during-suspend.patchAndy Green
Hum well that's the idea, Glamo did not play ball Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-reparenting-panic-sd-boot.patchAndy Green
We panic on SD boot now we changed Glamo order, because it didn't succeed to bring up mmcblk0p1. But, if you do loglevel=8 then it works OK. So we are racing with something... Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-probe-fail-bail.patchAndy Green
Backout from failed probe was quite broken. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19debug-glamo-drop-lcm-reset-during-glamo-probe.patchAndy Green
We shouldn't have to reset it in glamo probe Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-migrate-irq-init-before-register-init.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-irq-recursive-locking.patchAndy Green
Running heavily instrumented kernel, get report about glamo IRQ spinlock probem. [ 8.795000] ============================================= [ 8.795000] [ INFO: possible recursive locking detected ] [ 8.795000] 2.6.24 #782 [ 8.795000] --------------------------------------------- [ 8.795000] swapper/1 is trying to acquire lock: [ 8.795000] (&irq_desc_lock_class){++..}, at: [<c0077ae4>] handle_level_irq+0x24/0x120 [ 8.795000] [ 8.795000] but task is already holding lock: [ 8.795000] (&irq_desc_lock_class){++..}, at: [<c01be628>] glamo_irq_demux_handler+0x24/0x140 [ 8.795000] [ 8.795000] other info that might help us debug this: [ 8.795000] 1 lock held by swapper/1: [ 8.795000] #0: (&irq_desc_lock_class){++..}, at: [<c01be628>] glamo_irq_demux_handler+0x24/0x140 [ 8.795000] [ 8.795000] stack backtrace: [ 8.795000] [<c002ec28>] (dump_stack+0x0/0x14) from [<c006ad74>] (__lock_acquire+0x9a0/0xdec) [ 8.795000] [<c006a3d4>] (__lock_acquire+0x0/0xdec) from [<c006b264>] (lock_acquire+0xa4/0xc0) [ 8.795000] [<c006b1c0>] (lock_acquire+0x0/0xc0) from [<c02f7878>] (_spin_lock+0x44/0x78) [ 8.795000] [<c02f7834>] (_spin_lock+0x0/0x78) from [<c0077ae4>] (handle_level_irq+0x24/0x120) [ 8.795000] r6:c03e11c0 r5:0000005c r4:c03e11c0 [ 8.795000] [<c0077ac0>] (handle_level_irq+0x0/0x120) from [<c01be708>] (glamo_irq_demux_handler+0x104/0x140) [ 8.795000] r7:00000038 r6:c03e11c0 r5:00000008 r4:c03e0560 [ 8.795000] [<c01be604>] (glamo_irq_demux_handler+0x0/0x140) from [<c003c934>] (s3c_irq_demux_extint8+0x94/0xa4) [ 8.795000] r8:00000002 r7:00000003 r6:00000000 r5:c03df958 r4:00000000 [ 8.795000] [<c003c8a0>] (s3c_irq_demux_extint8+0x0/0xa4) from [<c0029048>] (__exception_text_start+0x48/0x64) [ 8.795000] r4:00000015 [ 8.795000] [<c0029000>] (__exception_text_start+0x0/0x64) from [<c0029a5c>] (__irq_svc+0x3c/0xb4) Patch removes desc->lock locking around glamo_irq_demux_handler... guess it is OK since we didn't clear interrupt source, can't recurse? Signed-off-by: Andy Green <andy@openmoko.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-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-19tracking-2.6.27-rc2-include-path-changes.patchAndy Green
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>
2008-11-19fix-glamo-turbo-host-interface.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19tracking-2.6.27-rc1-irqtype-falling-glamo.patchAndy Green
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19add-glamo-mci-slower-clocking-dynamic-switching.patchAndy Green
This patch gives glamo-mci a concept of a platform-defined dynamic clock slowing callback. It means that platform code can associate some completely external state to decide if we run the SD clock at normal rate or a rate divided by a module parameter "sd_slow_ratio", which you can set on kernel commandline like this: glamo_mci.sd_slow_ratio=8 you can also change it at runtime by echo 8 > /sys/module/glamo_mci/parameters/sd_slow_ratio If no platform callback is defined, then no slow mode is used. If it is defined, then the default division action is / 8, eg, 16MHz normal -> 2MHz slow mode. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-allow-full-sd-voltage-range-selection.patchAndy Green
Until now we just drove the SD Card at 3.3V all the time. But in fact we can do better, and use a voltage negotiated with the SD Card itself. With the shipping 512MB Sandisk SD Card, 2.7V is negotiated which gives 1.7dBm reduction in power on all the SD Card lines and should further reduce GPS perturbation during SD Card usage. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-suspend-resume-dram-and-engines.patchAndy Green
Two issues... we never took care to take down engines in suspend and bring them back in resume. This was part of the display corruption that could be seen briefly on resume. The other issue that made the "noise" corruption was bad ordering of resume steps. This patch simplifies (removing needless re-init) resume actions and makes explicit the suspend and resume steps. It also adds code to track which engines are up and push them down in suspend and bring them back in resume. The result is no more corruption of display buffer in suspend, it comes back completely clean. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-pcf50633-kill-white-splash-of-death-on-suspend.patchAndy Green
mach-gta02 meddles with the regulator platform struct after it is defined, leading to LCM power getting lost in suspend despite I set it to be left up. Fixing this finally removes the incredibly stubborn white LCM on suspend "flash". This is also going to be implicated in Sean McNeil's experience of monochromatic LCM after resume, which was previously attacked by resetting and re-initing the LCM from scratch. In addition, I realized that we take down core_1v3 in pcf50633 suspend action, this is happening near the start of suspend, so we are in a meta-race to finish suspend in a controlled way before the caps on core_1v3 run out (I only saw 23.3uF total). If it's true, this is where the weirdo sensitivity to timing during suspend is coming from. Therefore in this patch we also remove sleeps and dev_info() etc (which have to flush on serial console) from the pc50633 isr workqueue if we are in pcf50633 driver suspend state 1, ie, suspending... because we don't have time for it. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-resume-dependency-on-pcf50633.patchAndy Green
Glamo MCI has a resume order dependncy on pcf50633, it has to be able to power the SD slot via it. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19add-use-pcf50633-resume-callback-jbt6k74.patchAndy Green
Adds the resume callback stuff to glamo, then changes jbt6k74 to no longer use a sleeping workqueue, but to make its resume actions dependent on pcf50633 and glamo resume (for backlight and communication to LCM respectively) Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19OpenMoko => OpenmokoHolger Freyther
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
2008-11-19debug-glamo-add-lcd-regs-to-dump.patchwarmcat
Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamofb-cmd-mode-locking.patchAndy Green
Glamo "cmd mode" is modal, but nothing took care about locking. Also cmd mode was entered recursively in rotate_lcd(). Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19debug-glamo-dump-regs.patchwarmcat
From: Andy Green <andy@openmoko.com> Sigend-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-fake-reset-opcode-in-suspend.patchwarmcat
2008-11-19fix-lcm-reinit-post-resume.patchwarmcat
2008-11-19suspend-prelim1.patchmokopatches
2008-11-19glamo-mmc.patchmokopatches
2008-11-19smedia-glamo.patchmokopatches
[ FIXME: include/asm-arm/arch-s3c2410/irqs.h shouldn't contain device-specific changes. ] This is a Linux kernel driver for the Smedia Glamo336x / Glamo337x multi-function peripheral device. Signed-off-by: Harald Welte <laforge@openmoko.org>