| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
This patch is to register pwm as platform driver to keep the PWM-related
config when system is in suspend/resume. This could fix the following
issue after resume:
- HDQ read timeout
- LEDs blinked abnormally(if LEDs is driven by PWM)
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
Created an attachment (id=594) / BZ#79
Add missing platform_data that caused the GTA01 to crash on suspend/resume
The interface to the jbt6k74 driver changed slightly; this patch adds the
missing platform_data for the GTA01. This prevents a crash while suspending.
This patch also makes some minor changes to cleanup and clarify some debug
messages.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
Created an attachment (id=593) / from BZ#79
Updated patch to preserve the power state of the GPS on the GTA01
Currently the GPS is powered up after a suspend/resume occurs. This patch will
only power the GPS back up if it was powered up when the GTA01 suspended.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
Patch to register the SPI device and thus the save/resume for the display
This patch does *NOT* resolve this problem, but it does make things a bit
better. The SPI device name changed with 2.6.24, and the change was made for
the gta02 but never propagated to the gta01. With this change, you'll now see
the entries for the spi bus and the display controller in /sys; and the display
controller suspend/resume functions will be called.
(via BZ 79)
Signed-off-by: Mike Wester <mwester@dis.net>
|
|
- 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>
|
|
The bluetooth enable and modem reset switched the order in
gta02. Do not poke the bluetooth dongle when we want to reset
the modem.
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
If we build a kernel without gta01/gta02 the
machine_is_ macro will expand to (0) and the compiler will
optimize the if (0) {} away.
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Only enable or disable the interrupt if we see we are in the opposing state.
Also force that damn GSM download signal deasserted on probe at the time we
set the logical state for it to deasserted.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Similar to the neo1974_pm_gsm.c keep a static struct around. On suspend
we will save the current power state, on resume we will use this
information to enable power of the GPS only when it was powered on before.
This is passing basic tests with screen /dev/ttySAC1 on suspend and resume.
Only do this for the GTA02 as I don't have a gllin setup for the GTA01
I wonder why the suspend and resume code is not using gps_pwron_set and why
for the GTA02 we need to keep the state of the GPIOs, this should be done
by the s3c code.
Signed-Off-by: Holger Frether <zecke@openmoko.org>
|
|
GTA02_GPIO_nDL_GSM defaults to high/1. On resume do not enable the DL_GSM if
it was not enabled before. This is stopping the storm of interrupts.
Fix the logic in the download file handling. Downloads are disabled (0) when
the GTA02_GPIO_nDL_GSM is high (1). To enable downloading set
GTA02_GPIO_nDL_GSM to low (0, !on). Disable the jack interrupt while download
the is active. When disabling download we will get a couple of jack interrupts
but this is hardly avoidable.
Avoid reading the GPIO value if we do not even have a console set.
Signed-Off-by: Holger Freyther <zecke@openmoko.org>
|
|
Signed-Off-by: Holger Freyther <zecke@openmoko.org>
|
|
Signed-Off-by: Holger Freyther <zecke@openmoko.org>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
We used to drive output high into GPS unit in suspend
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>
|
