Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: 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>
|
|
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>
|
|
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>
|
|
Existing Glamo bit for stopping SD Card Clock when there is no
transfer taking place does not work. This patch adds stuff around
the transfer code to force the SD clock up when something is going on
and down when it is idle. This'll save a little power and noise ;-)
I tested it briefly and was able to SD Boot normally on Sandisk 512M.
Wider testing is appreciated.
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? ;)
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Reported-by: Mickey Lauer <mickey@openmoko.org>
AUX level detection is inverted based on GTA01 or 02
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] [neo1973 leds] Move from mutex to spinlock because we may not use mutexes
The led triggers may call set_brightness from atomic contexts. As
mutex_lock calls might_sleep and sleeping is not allowed in atomic contexts
we have to switch to spinlocks here.
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
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] [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
|
|
Subject: [PATCH] [janitor] Make checkpatch happy on the header files
|
|
Subject: [PATCH] [bq27000] Make the checkpatch.pl happy
|
|
Subject: [PATCH] Hacky CONFIG_NO_IDLE_HZ (dyn-tick) support for S3C24xx.
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
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>
|
|
Reported-by: Holger Freyther <zecke@openmoko.org>
length can be zero... blowing a divide by zero exception...
which somehow I don't get (?) Anyway the code is wrong and
this should fix it.
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>
|
|
|
|
make it happy
Call SET_NET_DEV to set a parent device. All other net drivers
are doing this and hald needs a parent to add the network device.
|
|
Reported-by: Graeme Gregory <graeme@openmoko.org>
Basically-solved-by: Graeme Gregory <graeme@openmoko.org>
Graeme found a while back that on resume, IISCON register in
s3c2442 does not show LRCK toggling in LRINDEX bit any more,
causing s3c24xx_snd_lrsync() to timeout and return an error,
aborting restart of any live stream that was playing at
suspend.
I confirmed it was true, meddled around for a bit looking
for some magic to restart LRCK or at least the reporting of
it, and in the end worked around it using the method noted
by Graeme: just ignore LRCK sync if it timed out. The worst
that could happen would be L and R swap for the duration of
stream that was suspended into but probably not even that.
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>
|
|
Two issues... we never took care to take down engines in suspend
and bring them back in resume. This was part of the display
corruption that could be seen briefly on resume. The other issue
that made the "noise" corruption was bad ordering of resume steps.
This patch simplifies (removing needless re-init) resume actions
and makes explicit the suspend and resume steps. It also adds
code to track which engines are up and push them down in suspend
and bring them back in resume.
The result is no more corruption of display buffer in suspend, it
comes back completely clean.
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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|