| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds a script that creates a "recovery kernel" image
from a recovery-uImage-moredrivers-... image. The use of these
recovery images is explained here:
http://wiki.openmoko.org/wiki/Freerunner_backup_kernel
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Suggested-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Colons are not very friendly for tar... scp has trouble too but
you can override that by prepending any path like ./ ... still
better to dilute the colon down to a _ avoiding - because it can
appear in branch names we use.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Keep a copy of last "moredrivers" config kernel built stamped with
branch and git head at build time.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This patch adds the branch and truncated head has to the version of the
kernel
# cat /proc/version
Linux version 2.6.26-andy-2.6.26:2b3bf342baac52b9-mokodev (agreen@pads.home.warmcat.com) (gcc version 4.1.2) #878 PREEMPT Sun Jul 27 14:45:25 BST 2008
Note this versioning is visible down /lib/modules
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
If the charger was removed, we fell through back to old
hdq-driven code with normally wrong but slightly random
results for charging LED behaviour in that circumstance
This patch makes us use the tracked charger status
callbacks alone if they are defined in the platform
data.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Uses bus_create_device_link to correctly create the gllin compat link.
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
|
|
Allows the direct creation of symlinks on /sys/bus/*/devices. This is needed
for a compat symlink from gta01-pm-gps.0 to neo1973-pm-gps.0 on the Openmoko
Neo1973 GTA01.
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
