Age | Commit message (Collapse) | Author |
|
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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
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>
|
|
From: Andy Green <andy@openmoko.com>
Sigend-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
|
|
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>
|
|
[ Stop kernel from hanging every once in a while during Glamo
initialization. ]
debug-glamo-fb-cmdqueue-wait-timeout.patch
From: warmcat <andy@warmcat.com>
|
|
|
|
|
|
[ 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>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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>
|
|
This one was accidentally left out during the rc1 mfd merge.
Signed-off-by: Samuel Ortiz <sameo@openedhand.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
- 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>
|
|
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
...
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|