aboutsummaryrefslogtreecommitdiff
path: root/drivers/mfd
AgeCommit message (Collapse)Author
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-mmc-ultiwrite-gone.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-glamo-mci-dont-filter-voltage-change.patchAndy Green
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-mci-ensure-more-than-74-clocks-after-power.patchAndy Green
We are meant to run SD_CLK a little while after power-on for the SD Card, but with the no idle clock changes we didn't take care about it. This makes us sleep a little bit before disabling clock if we just powered up the SD Card. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-possible-timeout-overflow.patchAndy Green
The MMC stack hands us a timeout calibrated in SD_CLK clocks, but the Glamo can only deal with up to 65520 clocks of timeout. If the stack handed us a request bigger than this, it would just wrap and the timeout we actually used would be way too short. With this patch if that happens, we use the longest timeout we can, 65520 clocks and give it our best shot. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-glamo-mci-set-default-drive-level-0.patchAndy Green
Tests on access to SD Card with Glamo drive level "0" show that it reduces SD_CLK energy at 1.5GHz by 24dBm compared to drive level 3. This puts it only 6dB above the background noise floor compared to 30dB and should make a solution for GPS trouble with SD Card in. SD card communication seems unaffected so far on the Sandisk 512MB card we ship. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19debug-add-glamo-drive-strength-module-param.patchAndy Green
Suggested-by: Werner Almesberger <werner@openmoko.org> This patch allows users to control two additional settings in Glamo MCI driver from kernel commandline or module parameters. First is Glamo drive strength on SD IOs including CLK. This ranges from 0 (weakest) to 3 (strongest). echo 0 > /sys/module/glamo_mci/parameters/sd_drive (Changes to this take effect on next SD Card transaction) or, from kernel commandline glamo_mci.sd_drive=0 On tests here with 0 strength, communication to SD card (shipped 512MB Sandisk) seemed fine, and a dd of 10MB urandom had the same md5 when written to cache as after a reboot. I set the default to 2. Second is whether we allow SD_CLK when the SD interface is idle. # stop the clock when we are idle (default) echo 0 > /sys/module/glamo_mci/parameters/sd_idleclk # run the SD clock all the time echo 1 > /sys/module/glamo_mci/parameters/sd_idleclk (changes take effect on next SD Card transaction) From kernel commandline, eg: glamo_mci.sd_idleclk=1 Normally you don't want to run the SD Clock all the time. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-scard-stop-on-resume.patchAndy Green
Reported-by: Ville-Pekka Vainio <vpivaini@cs.helsinki.fi> The reporter noticed SD Card clock is running again after resume. After looking at the code I saw I missed two tricks, this will force it off after resume and will do better generally depending on what the last SD Card packet was. Since bulk read packet is normally last action (which set the clock off even without this) the old patch worked for normal cases. But after resume, the last packet on the wire was not a bulk transfer and we didn't take care about the clock then. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19add-limit-sdcard-clk-cmdline.patchAndy Green
This patch allows you to control the maximum clock rate that will be selected for SD Card access, from the kernel commandline using glamo_mci.sd_max_clk=10000000 and also from echo 10000000 > /sys/module/glamo_mci/parameters/sd_max_clk although you have to suspend and resume to make the limit operational on the actual SD_CLK line. Clocks that are possible are divided down from ~50MHz, so 25000000, 16666666, 12500000, 10000000, etc. With Freerunner A5 revision that has 100R series resistors in SD Card signals, I didn't get reliable operation above 16MHz. With A6 revision the series resistors went down to 75R, maybe it can work at 25MHz. Reducing the clock rate is something to try if you find that your SD Card is not communicating properly with the default speed. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19fix-force-sdcard-clk-off-when-idle.patchAndy Green
Existing Glamo bit for stopping SD Card Clock when there is no transfer taking place does not work. This patch adds stuff around the transfer code to force the SD clock up when something is going on and down when it is idle. This'll save a little power and noise ;-) I tested it briefly and was able to SD Boot normally on Sandisk 512M. Wider testing is appreciated. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19Subject: [PATCH] glamo: Don't disable hwcursor for blinking and use vsync-wait.Andrzej Zaborowski
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-19Subject: [PATCH] Hardware glamo-fb cursor, some clean-up.Andrzej Zaborowski
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-19fix-glamofb-cmdqueue-timeout.patchAndy Green
loglevl=9 can cause failure to init glamo-fb problem seems to be too low timeout when text scrolling can delay commandqueue going empty 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-19fix-glamo-mci-defeat-ops-during-suspend.patchAndy Green
We need to be able to use the config option CONFIG_MMC_UNSAFE_RESUME that allows the rootfs to live on SD. But when we use this, it tries to send a reset command to the SD card during suspend -- and unfortunately many things like Power have suspended by then. This patch again rejects IO on the MMC device during suspend of the MMC device, and it gives the result the rootfs on SD card works okay. Signed-off-by: Andy Green <andy@openmoko.com>
2008-11-19glamo-cmdqueue-bandaid.patchmokopatches
[ Stop kernel from hanging every once in a while during Glamo initialization. ] debug-glamo-fb-cmdqueue-wait-timeout.patch From: warmcat <andy@warmcat.com>
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>
2008-11-01missing dependencies on HAVE_CLK in drivers/mfdAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-24mfd: Make WM8400 depend on I2C until SPI is submittedMark Brown
Otherwise we could build in WM8400 but not I2C. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-24mfd: add missing Kconfig entry for da903xSamuel Ortiz
This one was accidentally left out during the rc1 mfd merge. Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-22mfd: check for platform_get_irq() return value in sm501Roel Kluin
sm501_devdata->irq is unsigned, while platform_get_irq() returns a signed int. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-22mfd: use pci_ioremap_bar() in sm501Arjan van de Ven
Use the newly introduced pci_ioremap_bar() function in drivers/mfd. pci_ioremap_bar() just takes a pci device and a bar number, with the goal of making it really hard to get wrong, while also having a central place to stick sanity checks. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-22mfd: Don't store volatile bits in WM8350 register cacheMark Brown
This makes the contents of the cache clearer and fixes incorrect initialisation of the cache for partially volatile registers. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-22mfd: don't export wm3850 static functionsStephen Rothwell
October 10th linux-next build (powerpc allyesconfig) failed like this: drivers/mfd/wm8350-core.c:1131: error: __ksymtab_wm8350_create_cache causes a section type conflict Caused by commit 89b4012befb1abca5e86d232bc0e2a797b0d9825 ("mfd: Core support for the WM8350 AudioPlus PMIC"). wm8350_create_cache is not used elsewhere, so remove the EXPORT_SYMBOL. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-22mfd: twl4030 IRQ handling updateDavid Brownell
- Move it into a separate file; clean and streamline it - Restructure the init code for reuse during secondary dispatch - Support both levels (primary, secondary) of IRQ dispatch - Use a workqueue for irq mask/unmask and trigger configuration Code for two subchips currently share that secondary handler code. One is the power subchip; its IRQs are now handled by this core, courtesy of this patch. The other is the GPIO module, which will be supported through a later patch. There are also minor changes to the header file, mostly related to GPIO support; nothing yet in mainline cares about those. A few references to OMAP-specific symbols are disabled; when they can all be removed, the TWL4030 support ceases being OMAP-specific. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-20Merge branch 'genirq-v28-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip This merges branches irq/genirq, irq/sparseirq-v4, timers/hpet-percpu and x86/uv. The sparseirq branch is just preliminary groundwork: no sparse IRQs are actually implemented by this tree anymore - just the new APIs are added while keeping the old way intact as well (the new APIs map 1:1 to irq_desc[]). The 'real' sparse IRQ support will then be a relatively small patch ontop of this - with a v2.6.29 merge target. * 'genirq-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (178 commits) genirq: improve include files intr_remapping: fix typo io_apic: make irq_mis_count available on 64-bit too genirq: fix name space collisions of nr_irqs in arch/* genirq: fix name space collision of nr_irqs in autoprobe.c genirq: use iterators for irq_desc loops proc: fixup irq iterator genirq: add reverse iterator for irq_desc x86: move ack_bad_irq() to irq.c x86: unify show_interrupts() and proc helpers x86: cleanup show_interrupts genirq: cleanup the sparseirq modifications genirq: remove artifacts from sparseirq removal genirq: revert dynarray genirq: remove irq_to_desc_alloc genirq: remove sparse irq code genirq: use inline function for irq_to_desc genirq: consolidate nr_irqs and for_each_irq_desc() x86: remove sparse irq from Kconfig genirq: define nr_irqs for architectures with GENERIC_HARDIRQS=n ...
2008-10-19mfd: ucb1400 needs GPIOAndrew Morton
ia64 allmodconfig: In file included from include/linux/ucb1400.h:27, from drivers/mfd/ucb1400_core.c:24: include/asm-generic/gpio.h: In function `gpio_get_value_cansleep': include/asm-generic/gpio.h:147: error: implicit declaration of function `gpio_get_value' include/asm-generic/gpio.h: In function `gpio_set_value_cansleep': include/asm-generic/gpio.h:153: error: implicit declaration of function `gpio_set_value' drivers/mfd/ucb1400_core.c: At top level: Signed-off-by: Samuel Ortiz <sameo@openedhand.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2008-10-19mfd: ucb1400 sound driver uses/depends on AC97_BUS:Randy Dunlap
ERROR: "ac97_bus_type" [drivers/mfd/ucb1400_core.ko] undefined! Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2008-10-19mfd: Don't use NO_IRQ in WM8350Mark Brown
NO_IRQ is only defined on some architectures - the general way to test for an invalid IRQ in the modern kernel is by comparing with zero. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-19mfd: update TMIO drivers to use the clock APIIan Molton
This patch updates the remaining two TMIO drivers to use the clock API rather than callback hooks into platform code. Signed-off-by: Ian Molton <spyro@f2s.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-19mfd: twl4030-core irq simplificationDavid Brownell
Simplify twl4030 IRQ handling by removing a needless custom flow handler. The top level IRQs, from the PIH, are well suited for handle_simple_irq() ... they can't be acked or masked. Switching resolves some issues with how IRQs were dispatched. Notably, abuse of desc->status, IRQ accounting, and handling of various faults. In short, use standard genirq code. Drivers that request_irq() to the PIH will need to pay more attention to things like setting IRQF_DISABLED (since it's no longer ignored), and making I2C calls from handlers (you'll need a lockdep workaround). Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-19mfd: add base support for Dialog DA9030/DA9034 PMICsEric Miao
DA9030 (a.k.a ARAVA) and DA9034 (a.k.a MICCO) are PMICs designed by Dialog Semiconductor, usually found on PXA-based platforms. These PMICs are I2C-based, multi-function devices, usually with LEDs, PWMs for backlight, BUCKs and LDOs, ADCs and touchscreen controller (on DA9034). This is the base support for the I2C operations, event registration and handling, sub-devices management. Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Liam Girdwood <lrg@kernel.org> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-19mfd: TWL4030 core driverDavid Brownell
This patch adds the core of the TWL4030 driver, which supports chips including the TPS65950. These chips are multi-function; see http://focus.ti.com/docs/prod/folders/print/tps65950.html Public specs are in the works. For now, the block diagram on the second page of the datasheet is fairly informative. There are some known issues with this core code. Most notably, the IRQ dispatching needs simplification (to use more of genirq), generalization (integrating support for secondary IRQ dispatch as well as primary, and removing the build dependency on OMAP), and then probably updating to leverage threaded IRQ support (expected to arrive in mainline "soon"). Once the core is in mainline, drivers for other parts of this chip can follow its lead and start swimming upstream too. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-19mfd: support tmiofb cell on tc6393xbDmitry Baryshkov
Add support for tmiofb cell found in tc6393xb chip. Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Cc: Ian Molton <spyro@f2s.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
2008-10-19mfd: add OHCI cell to tc6393xbDmitry Baryshkov
Add information regarding OHCI cell of the tc6393xb Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com> Acked-by: Ian Molton <spyro@f2s.com> Signed-off-by: Samuel Ortiz <sameo@openedhand.com>