| Age | Commit message (Collapse) | Author |
|---|
|
Without this the backlight remains stubbornly down on resume
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>
|
|
Stop the debugging stuff, see if that impacts resume error (not really, it
was actually Glamo)
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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
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>
|
|
Qi does not touch the backlight, we have to do it in Linux now
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>
|
|
- pca9632 is a LED driver which will be adopted in gta03.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
This patch is a work-around solution to correct charging indication logic.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
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>
|
|
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>
|
|
Uses bus_create_device_link to correctly create the gllin compat link.
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Reported-by: Holger Freyther <zecke@openmoko.org>
We harmlessly repeated PMU platform callbacks about charging state twice.
Clean it up and leave it to pcf50633_charge_enable() to report once.
Also tidies the sequencing so we set current limit before we enable
charger now.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Setting the current limit directly and enabling the charger
isn't anyone's business except pcf50633 driver itself, so these
two functions should not be exported and become static.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Suggested-by: Sean McNeil <sean@mcneil.com>
To see if some subtle race is involved, Sean has tried
removing syslog traffic during resume and found he was
not seeing the resume crash any more. We're giving it
a try to see if it changes the behaviour for anyone
else. It would mean we have a pretty fine race in there
somewhere.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We at least always enabled backlight on resume, this patch
changes us to set backlight back to last requested backlight
brightness level on resume. Note it means that you can
resume with screen blanked, but it should come back if that
happened with touchscreen action as usual.
/sys/class/backlight/pcf50633-bl/actual_brightness
and
/sys/class/backlight/pcf50633-bl/brightness
seem to agree after resume when reportedly they didn't before.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This patch adds a sysfs node:
/sys/class/i2c-adapter/i2c-0/0-0073/force_usb_limit_dangerous
it allows to force the charging limit regardless of the one chosen
by pcf50633 kernel driver. As such, if you write a charging limit
here that is not suitable for the power source, and the power source
is not current limited on its side, it could draw more current than
your power source can handle, burn down you house, etc.
If you're certain that your power supply can handle it, you can use
this on your own responsibility to make the amount drawn by the
PMU match what you believed your power supply could handle.
Example usage, in case where you have a dumb 500mA USB charger that
does not have the ID resistor:
# cat /sys/class/i2c-adapter/i2c-0/0-0073/charger_type
host/500mA usb mode 100mA <=== dumb charger does not ennumerate us
# echo 500 > /sys/class/i2c-adapter/i2c-0/0-0073/force_usb_limit_dangerous
# cat /sys/class/i2c-adapter/i2c-0/0-0073/charger_type
host/500mA usb mode 500mA
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We leave SECOND unmasked on resume, it's like the
situation at probe() time, but there it makes us
turn SECOND off after coldplug action. So we need
to act like after that has happened, not exactly
like what we do at probe / init time.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Subject: [PATCH] [pcf50633] Avoid ooops on start with inserted usb cable
The pcf50633_global might not be initialized when we get the first
usb interrupt. We would oops inside the dev_err because we made up
a struct device.
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Subject: [PATCH] [pcf50633] Report more events to userspace using the default callback
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Subject: [PATCH] [battery] Make the bq27000 send an uevent when the charging state possible changed
Remove the todo entries from the pcf50633, make the mach-gta02
call the bq27000 driver from the pmu callback.
|
|
Subject: [PATCH] [janitor] make checkpatch.pl happy
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Everywhere in the sources except the probe function the context
pointer is called "pcf"... in there it's called "data" for some
reason. This stops confusion by changing it to be "pcf" in there
as well.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
pcf50633.c shouldn't know GTAxx at all. Move to using a
platform callback to allow definition of platform devices
with pcf50633 as parent device (good for enforcing suspend /
resume ordering). Remove all code references to GTAxx from
the sources (one string left for compatability).
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Backlight wasn't off by default on resume, so it was never really
deferred (until LCM is initialized). This fixes that and so removes
the brief white screen between pcf50633 resume and LCM init.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Disable pcf interrupt (not for wake, just as interrupt) in
suspend, re-enable it again just before we force-call the
workqueue function at end of pcf resume, which leads to
pcf interrupt source registers getting cleared so it can
signal an interrupt normally again.
This change ends the uncontrolled appearance of pcf interrupts
during resume time which previously caused the work to attempt
to use the I2C stuff before i2c host device had itself resumed.
Now the isr work is only queued, and the isr work function called,
definitively after pcf resume completes.
In suspend time, the work function may have been queued some
time before and be pending, and it could still show up at a
bad time. Therefore if the work function sees that it is
coming since the start of pcf50633 suspend function, it
aborts without attempting to read the pcf interrupt regs,
leaving them for resume to take care of.
USB current limit and no battery work functions are also made
aware of suspend state and act accordingly.
Lastly I noticed that in early resume, i2c_get_clientdata(&pcf->client)
returns NULL, presumably because i2c device is still suspended. This
could easily make trouble for async events like interrupt work,
since pcf pointer is the client data. Disabling appearance of the
work until after pcf50633 resume will also avoid that.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Use an enum to define pcf50633 suspend / resume state.
Add PCF50633_SS_RESUMING_BUT_NOT_US_YET to be the state
early in resume: add platform driver resume function just
to set this state so we can differentiate between early
resume and late suspend.
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>
|
|
Sean McNeil reports that he doesn't get pcf50633 interrupts any
more after resume. This adds back the call to ISR work in
the resume, removal of which is probably to do with it.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
pcf50633 needs to take responsibility for managing current limit
changes asycnhrnously, ie, from USB stack enumeration. It's a feature of
pcf50633 not mach-gta02.c, and we can do better with taking care about
keeping it from firing at a bad time in there too.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Simplify and speed up bulk sequential I2C actions in pcf50633
the time savings are pretty considerable and so is the simplification
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
More pcf50633 major time saving by using i2c bulk autoincrement. Code
reduction too by using array for time elements.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Improve pcf50633 interrupt service scheduling to enforce only servicing
when resume action is completed
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
After protecting pcf50633 read and write primitives against
operation after suspend or before resume (by blowing a
stack_trace()) I saw glamo-mci was trying to use pcf50633
at these bad times on its own suspend and resume. Since that
part was already done via platform callback, I added an
export in pcf50633 that tells you if it is ready or busy,
and used it to defer (resume power on case) or ignore
(suspend power off case, since pcf50633 already did it)
the mci power call.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
- speed up suspend and resume by using one hit i2c bulk transactions
- don't bother storing int mask set on suspend, the default one is
what we use anyway
- put stack_trace() on pcf50633 low level access that fire if we
try to touch them before we resumed
- cosmetic source cleanup
- reduces resume time for pcf50633 from 450ms to 255ms
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>
|
|
Adds resume dependency support to pcf50633
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Creates a new behaviour requested by Will that the red LED on GTA02
is lit during battery charging.and goes out when the battery is full.
This is done by leveraging the PMU interrupts, but in one scenario
there is no interrupt that occurs, when the battery is replaced after
being removed with the USB power in all the while. So a sleepy work
function is started under those circumstances to watch for battery
reinsertion or USB cable pull.
100mA limit was not being observed under some conditions so this was
fixed and tested with a USB cable with D+/D- disconnected. 1A
charger behaviour was also tested.
Showing the charging action exposes some inconsistency in pcf50633
charging action. If your battery is nearly full, it will keep
charging it at decreasing current even after it thinks it is at
100% capacity for a long while. But if you pull that same battery
and re-insert it, the charger state machine in pcf50633 believe it is
full and won't charge it.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Currently we are willing to wake from sleep from
pcf50633 interrupts we don't actually do anything about
even when we wake (somewhat puzzled).
Let's disable some of these wake sources.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
If you have U-Boot with uboot-add-find-wake-reason.patch, this
patch will get you a wake reason report from
cat /sys/devices/platform/neo1973-resume.0/resume_reason
it looks like this:
EINT00_ACCEL1
EINT01_GSM
EINT02_BLUETOOTH
EINT03_DEBUGBRD
EINT04_JACK
EINT05_WLAN
EINT06_AUXKEY
EINT07_HOLDKEY
EINT08_ACCEL2
* EINT09_PMU
adpins
adprem
usbins
usbrem
rtcalarm
second
onkeyr
onkeyf
exton1r
exton1f
exton2r
exton2f
exton3r
exton3f
* batfull
chghalt
thlimon
thlimoff
usblimon
usblimoff
adcrdy
onkey1s
lowsys
lowbat
hightmp
autopwrfail
dwn1pwrfail
dwn2pwrfail
ledpwrfail
ledovp
ldo1pwrfail
ldo2pwrfail
ldo3pwrfail
ldo4pwrfail
ldo5pwrfail
ldo6pwrfail
hcidopwrfail
hcidoovl
EINT10_NULL
EINT11_NULL
EINT12_GLAMO
EINT13_NULL
EINT14_NULL
EINT15_NULL
This shows a problem, false wake from suspend due to battery full
Signed-off-by: Andy Green <andy@openmoko.com>
|
