| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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>
|
|
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>
|
|
Charger trigger stuff goes and asks for POWER_SUPPLY_PROP_STATUS
to figure out what the charger state is. But until now, we only
reported there what we found out from HDQ, and the HDQ registers
are not updated very often in the coulomb counter, it can be 4
or more second lag before it tells us about what it experiences.
When we react to USB insertion and only after 500ms debounce tell
power_supply stuff that something changed, it most times will
see old pre-USB-insertion state from bq27000 over HDQ at that time
and will report it ain't charging, buggering up the LED trigger
tracking.
This patch maintains distance between bq27000 and pcf50633 by
having platform callbacks in bq27000 that it can use to ask about
definitive charger "online" presence and "activity", whether the
charger says it is charging. If these callbacks are implemented
(and we implement them in this patch up in mach_gta02.c) then
this information is used in preference to what is found from
HDQ.
Result is if you set the LED trigger like this:
echo bat-charging > /sys/devices/platform/gta02-led.0/leds/gta02-aux:red/trigger
then it lights up properly on USB insertion now, goes away on
removal properly, as as far as I saw, when charging stops too.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
My FreeRunner's load average was leveling off at 2.00 as a result of
these two kernel threads:
SDIO Helper D c02b4500 0 255 2
[<c02b4298>] (schedule+0x0/0x2d4) from [<c02b4040>] (__down+0x100/0x158)
[<c02b3f40>] (__down+0x0/0x158) from [<c02b3e2c>] (__down_failed+0xc/0x20)
r7:00000000 r6:c01fbd64 r5:c7cb7134 r4:c7d58000
[<c01fa6fc>] (CardDetectHelperFunction+0x0/0x1ac) from [<c01fbd80>] (HelperLaunch+0x1c/0x28)
r5:c7cb7134 r4:c7cb7134
[<c01fbd64>] (HelperLaunch+0x0/0x28) from [<c005bbd0>] (kthread+0x60/0x94)
r4:c7d58000
[<c005bb70>] (kthread+0x0/0x94) from [<c0048f7c>] (do_exit+0x0/0x744)
r6:00000000 r5:00000000 r4:00000000
SDIO Helper D c02b4500 0 259 2
[<c02b4298>] (schedule+0x0/0x2d4) from [<c02b4040>] (__down+0x100/0x158)
[<c02b3f40>] (__down+0x0/0x158) from [<c02b3e2c>] (__down_failed+0xc/0x20)
r7:c0382bb4 r6:c0382b34 r5:c7d5a000 r4:00000001
[<c01f9104>] (SDIOIrqHelperFunction+0x0/0x29c) from [<c01fbd80>] (HelperLaunch+0x1c/0x28)
r8:00000000 r7:00000000 r6:c01fbd64 r5:c0382bb4 r4:c0382bb4
[<c01fbd64>] (HelperLaunch+0x0/0x28) from [<c005bbd0>] (kthread+0x60/0x94)
r4:c7d5a000
[<c005bb70>] (kthread+0x0/0x94) from [<c0048f7c>] (do_exit+0x0/0x744)
r6:00000000 r5:00000000 r4:00000000
This fixes them to use interruptible sleep primitives while waiting in
their main loops, as is conventional for kernel threads. They can't
actually be interrupted since kernel threads ignore all signals, but
by sleeping this way they get classified as long term waiters, and
don't get counted as running for purposes of load average calculation.
This is intended as a minimal fix. In the longer term, it'd probably
make sense to replace the semaphores with completions or something,
and to do away with some of these StudlyCapped wrapper functions.
Signed-off-by: Jason Uhlenkott <jasonuhl@jasonuhl.org>
--
This is untested, but what could possibly go wrong? ;)
|
|
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 happy on the header files
|
|
This patch introduces a new resume debugging concept: if we
get an OOPS inbetween starting suspend and finishing resume, it
uses a new "emergency spew" device similar to BUT NOT REQUIRING
CONFIG_DEBUG_LL to dump the syslog buffer and then the OOPS
on the debug device defined by the existing CONFIG_DEBUG_S3C_UART
index. But neither CONFIG_DEBUG_LL nor the S3C low level configs
are needed to use this feature.
Another difference between this feature and CONFIG_DEBUG_LL is that
it does not affect resume timing, ordering or UART traffic UNLESS
there is an OOPS during resume.
The patch adds three global exports, one to say if we are inside
suspend / resume, and two callbacks for printk() to use to init
and dump the emergency data. The callbacks are set in s3c serial
device init, but the whole structure is arch independent.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Reported-by: John Lee <john_lee@openmoko.com>
We don't reset the devices either at init or resume, where init
means use the BOOT bit to reload device calibration coefficients
from internal EEPROM. John Lee saw brain-damaged behaviour after
resume and sometimes after boot (since it may not have lost power
to force a BOOT itself that makes sense).
This patch
- adds a diagnostic dump feature down /sys
- forces BOOT action on init and resume, and waits for
completion
- makes sure XYZ capture is enabled on resume
- adds some constants in the .h and removes some magic numbers
in the code by using them
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Touchscreen on GTA01-02 experiences noise on the channel that serves the
"tall axis" of the LCM. The sample quality of the other axis is good.
The bad samples have a characteristic of one shot excursions that can
reach +/- 20% or more of the sample average.
Previously, we had a simple averaging scheme going in the touchscreen
driver that summed up 32 x and ys and then divided it by 32. This patch
first tidies up the existing code for style, then adds a new "running
average" concept with a FIFO. The running average is separate from the
summing average mentioned above, and is accurate for the last n samples
sample-by-sample, where n is set by 1 << excursion_filter_len_bits in the
machine / platform stuff.
The heuristic the patch implements for the filtering is to accept all
samples, but tag the *previous* sample with a flag if it differed from
the running average by more than reject_threshold_vs_avg in either
axis. The next sample time, a beauty contest is held if the flag was
set to decide if we think the previous sample was a one-shot excursion
(detected by the new sample being closer to the average than to the
flagged previous sample), or if we believe we are moving (detected by
the new sample being closer to the flagged previous sample than the
average. In the case that we believe the previous sample was an
excursion, we simply overwrite it with the new data and adjust the
summing average to use the new data instead of the excursion data.
I only tested this by eyeballing the output of ts_print_raw, but it
seemed to be quite a bit better. Gross movement appeared to be
tracked fine too. If folks want to try different heuristics on top
of this patch, be my guest; either way feedback on what it looks like
with a graphical app would be good.
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Defines a way for drivers to defer execution of resume callbacks
until one or more other driver they are dependent on has itself
resumed.
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>
|
|
This patch improves the smoothness of suspend and resume action.
Taking out CONFIG_PM_DEBUG allows much more rapid resume (the low level
serial traffic appears to be synchronous)
Added a platform callback in jbt driver and support in pcf50633 so we
can defer bringing up the backlight until the LCM is able to process
video again (which must happen after the glamo is up and producing
video beacuse the LCM is hooked to glamo SPI)
GTA01 should not be affected by all this as the callback will default
to null and it is on pcf50606
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Holger got beaten to it on mainline, they provide a
s3c2410_gpio_irq2pin() instead of the name he used.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
- Any setting of any PIN on bank B will undo the LED setting.
Introduce neo1973_gpb_set_pin to set the PIN in a way not losing
the LED or any other shadowed setting.
- Update users of GPBXY for gta01 and gta02.
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
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>
|
|
Samsung SoC
Use this irq_to_gpio in the neo1973 keyboard driver
|
|
Add function
int gta02_get_pcb_revision(void)
which returns state of GTA02 PCB revision pins. It is also called
and logged during boot with KERN_INFO. The results look like:
b9 b8 b2 b1 b0
GPD4 GPD3 GPD0 GPC15 GPC13
GTA02 A5 and before: 0x000
GTA02 A6 : 0x001
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Add platform stuff to deal with going in and out of suspend
so the motion sensor IO is not driving high into unpowered sensors
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
|
|
|
|
|
|
On GTA02 we use FIQ to manage the vibrator IO now. That
is necessary because we stole timer3 from doing hw pwm
for vibrator. This keeps the same UI in /sys but does
"bitbang pwm" on the same vibrator GPIO
From: Andy Green <andy@openmoko.com>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This makes the FIQ stuff specific to one of the timers on the
s3c244x and adds the platform stuff for fiq in the gta02 init
Currently one sysfs node is exposed, a count of FIQ events
cat /sys/devices/platform/sc32440_fiq.0/fiq/count
From: Andy Green <andy@openmoko.com>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Adds a C-based FIQ ISR which is very convenient (and unusual --
normally you have to do FIQ ISR in assembler only).
Based on my article:
http://warmcat.com/_wp/2007/09/17/at91rm9200-fiq-faq-and-simple-example-code-patch/
Implemented as a platform device and driver.
Suspend / resume is tested and works.
Signed-off-by: Andy Green <andy@warmcat.com>
|
|
|
|
Modify GTA02 power manager for bluetooth.
1. Default power value isn't correct. Now we set pcf50633 LDO4 to 3.2 voltage.
2. Separate GTA01 and GTA02 source code.
3. Add pcf50633 API for enable register.
|
|
Moved shared PMU code from pcf50606.h and pcf50633.h (which prevented inclusion
of both at the same time) to pcf506xx.h
- include/linux/pcf50606.h (struct pmu_voltage_rail, enum pmu_event, pmu_cb):
moved to pcf506xx.h
- include/linux/pcf50633.h (struct pmu_voltage_rail, enum pmu_event, pmu_cb):
moved to pcf506xx.h
Signed off-by: Werner Almesberger <werner@openmoko.org>
|
|
|
|
This is a Linux driver for the STmicro LIS302DL 3-axis accelerometer.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
|
|
|
|
[ 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>
|
|
|
