Age | Commit message (Collapse) | Author |
|
Work in progress.
|
|
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>
|
|
Signed-off-by: Sean McNeil <sean@mcneil.com>
|
|
Subject: [PATCH] glamofb: Initialize only visible part of the memory.
It takes lots of time (0.5 seconds) to initialize the whole memory. As
only the visible part matters, we could just initialize that part.
Signed-off-by: Chia-I Wu <olv@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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
More effort to refine power code that does the suspend and resume actions
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
Big chunk of trying to own Glamo resume and not really succeeding
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
All that stuff should be enforced by device tree now, out with it
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Hum well that's the idea, Glamo did not play ball
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
Backout from failed probe was quite broken.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We shouldn't have to reset it in glamo probe
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
If we ever fall through to the yield when we turned off interrupts...
it wouldn't be pretty.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Trial to see if (mainly 32-bit) memcpy is any better than u16 loop
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
The delay versions of the access to registers were based on a misunderstanding of
the Glamo docs: it can force nWAIT differently depending on the access type. Therefore
we don't need to take special care about delays on CPU side.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Removed unused variable.
Signed-off-by: Nelson Castillo <nelsoneci@gmail.com>
|
|
The function glamo_mci_reset is not being used. Let's comment it out.
Signed-off-by: Nelson Castillo <nelsoneci@gmail.com>
|
|
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>
|
|
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>
|
|
Remove dead code and coding style fixes. Purely cosmetic.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|