| Age | Commit message (Collapse) | Author |
|---|
|
Fix spelling error on function name
Signed-off-by: Simon Kagstrom <simon.kagstrom@gmail.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This cleans out some random externs in C files that checkpatch does not like
and introduces a couple of .h files to contain them. Plus some other minor
checkpatch style complaints.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Set the UART FIFO to trigger earlier on the GTA01 device to minimize
UART overruns from the GSM.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
This patch adds the gta01 backlight callback that defers the
restoring of the backlight until after the jbt driver has
resumed. This doesn't eliminate the flashing of the LCD on
the gta01, but it reduces it considerably.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
This patch ensures that no console data will go the UART while
the GSM mux is switched to the GSM. This is necessary despite
the code that disables the console due to the fact that the
console resumes before the neo1973_pm_gsm driver, and consoles
always resume in the "on" state.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
Add the basic GSM flowcontrol code.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
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 uses the new glamo-mci slow clock ratio
patch in order to dynamically reduce SD Card clock
rate when the GPS unit is powered on GTA02.
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>
|
|
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>
|
|
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>
|
|
A few questions have been flying around about how optimal
our waitstates are for various things including Glamo.
This patch introduces new sysfs nodes
/sys/devices/platform/neo1973-memconfig.0/BANKCON0
...
/sys/devices/platform/neo1973-memconfig.0/BANKCON7
If you cat them you get translated info about bus speed on
that chip select, eg,
# cat /sys/devices/platform/neo1973-memconfig.0/BANKCON1
BANKCON1 = 0x00000A40
Type = ROM / SRAM
PMC = normal (1 data)
Tacp = 2 clocks
Tcah = 0 clocks
Tcoh = 1 clock
Tacc = 3 clocks
Tcos = 1 clock
Tacs = 0 clocks
You can write them in hex too
# echo 0x200 > /sys/devices/platform/neo1973-memconfig.0/BANKCON1
The write format for BANKCON0 - 5 looks like this
b1..b0 PMC Page Mode Config
b3..b2 Tacp Page Mode Access Cycle
b5..b4 Tcah Address hold after CS deasserted
b7..b6 Tcoh CS hold after OE deasserted
b10..b8 Tacc Access Cycle Period
b12..b11 Tcos CS setup before OE asserted
b14..b13 Tacs Address setup before CS asserted
BANKCON 6 and 7 have two extra bits
b16..b15 MT Memory type (00=ROM/SRAM, 11=DRAM)
If it's ROM/SRAM, the rest of the bits are as described above.
For DRAM
b1..b0 SCAN Column address number
b3..b2 RAS to CAS delay
The patch is intended to let people experiement on their own. But
of course you will crash things for sure if the timing is wrong, and
you can also trash SD Card data if you make Glamo unstable, so remove
it or remount ro first. Other horrible things are possible, but
because the settings aren't sticky, you should always be able to
recover by either normal reboot usually or at worst NOR boot and then
dfu. Most likely you will just crash your session and have to reboot
if your settings are bad, but consider yourself warned bad things are
possible. :-)
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
During the suspend current reduction campaign on suspend I
forced the GPS UART to be GPIO and to drive 0 into the GPS
unit so we would not burn current there. On resume it lets
the pins act as UARTs again. But really, we should do this
all the time that the GPS unit is off, lest we leak it
enough power to hold internal state and make trouble.
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>
|
|
Add missing initialization for the touchscreen driver for the
gta01 platform.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
- add an interrupt for ar6k wifi module
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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] Hacky CONFIG_NO_IDLE_HZ (dyn-tick) support for S3C24xx.
|
|
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>
|
|
A panic is silent on GTA02, it would be good if we got a little hint
if we are crashing (eg, in suspend / resume) from a panic instead of
a deadlock, etc. On a normal PC i8042 blinks the keyboard lights if
we panic, this patch causes AUX to flash at 5Hz in event of a panic.
Tested by giving kernel fake root= that didn't exist.
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>
|
|
Whoops left it up in 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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
The LCM spins for 100ms during resume for not much reason. Leave it powered
(it is meant to pull uA when suspended) and get nice fast resume to video.
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>
|
|
Glamo MCI power setting stuff spins on pcf50633
but it won't hurt if it gives up after a second or
two instead of stalling the resume silently.
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>
|
|
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>
|
|
|
|
Update this old code to clk API, I2C changes, official GPIO API
various struct changes, explicit readl() writel(), DMA API changes.
Still not ready for actual use (eg, I2C) but a LOT closer.
Compiles on 2.6.24 without errors or warnings now.
Use CONFIG_S3C2440_CAMERA=y in .config
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This is the kernel side of an old (2004) samsung camera driver for 2440
It doesn't compile on modern kernel yet, this patch introduces it into the
kernel tree without gross mods, so it is broken code we can start to work on
|
|
Adds the somewhat simpler resume source support for GTA01
since PMU is not a wake source
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>
|
