| Age | Commit message (Collapse) | Author |
|---|
|
style cleanups for accel threshold setting patch
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Hi!
First: Unfortunately, the freerunner currently wakes up immediately on
suspend when the accelerometer IRQ is selected as a wakeup source. I'm
posting this for comments and if someone else wants to have a look at
this problem.
The patch should be safe to apply even though the sleep portion doesn't
work - as long as it's configured it will not disturb anything.
// Simon
--
lis302dl-configure-wakeup-interrupts.patch
From: simon.kagstrom <simon.kagstrom@gmail.com>
First: Unfortunately, the freerunner currently wakes up immediately on
suspend when the accelerometer IRQ is selected as a wakeup source.
Add configuration of wakeup/freefall interrupts through a sysfs
interface. Configuration is done through echoing a value of the
form
X Y Z THRESHOLD DURATION SPEC
to freefall_wakeup_1/2. X, Y and Z are threshold values, given as a
value > 0, < 0 or 0 to specify if an interrupt should be generated for
high or low thresholds or neither (off). THRESHOLD specifies the
threshold that must be exceeded. DURATION specifies the time in
milliseconds for which the acceleration should be measured. SPEC is
either '1' or '0' and specifies if the thresholds should be taken all
together or one at a time ('and' or 'or' mode).
Echoing '0' to the file turns off the interrupts.
Example:
echo "1 1 1 60 60 0" > freefall_wakeup_1 # Turn on x,y,z, 60ms/60 threshold, or-mode
echo "0" > freefall_wakeup_1 # Turn off interrupt
The hardware supports two simulataneous wakeup sources to be configured,
but the freerunner only connects one of the interrupt outputs. The patch
exports both. Similarly, only the "top" accelerometer can be used as a
wake-up source, and it's not possible to generate DATA_READY interrupts
while the wakeup interrupts are active.
Signed-off-by: Simon Kagstrom <simon.kagstrom@gmail.com>
|
|
Subject: [PATCH] [gta02] Disable hardware ECC unless we get instructed to enable it
This is restoring the old behavior in regard to ECC. Even if
hardware ECC was compiled in we didn't use it. Make this a runtime
option. If the bootloader passes hardware_ecc we will enable the
hardware ECC for real.
|
|
Subject: [PATCH] Revert "s3c2440-nand-disable-hwecc.patch"
This reverts commit 1d89da736ed33d3f7c398fb9f8dfddecb7c7c7a9.
|
|
This patch fixes module unloading for the accelerometer (actually module
loading failed before). The two problems were that the interrupt was not
unregistered, and that the device was left in a "strange" state.
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>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
We failed to report status of "discharging", instead reporting
"not charging" even if we knew that the charger was not present.
This patch corrects it and reports "discharging" when charger
is absent.
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>
|
|
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 is the pcf50606 equivalent of the pcf50633 patch that
disables interrupts from the chip until after resume is complete.
In order to ensure no data is lost, the work function is called
post-resume to process any pending interrupts.
Most of the code was quite literally re-used from Andy Green's
original patch.
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>
|
|
gta0x-log-serial-rx-error.patch
This patch causes a KERN_DEBUG message to be printed each time an
error status is read from a UART. This is intended to facilitate
the reporting of more useful problem and bug reports from users
in the field.
Signed-off-by: Mike Westerhof <mwester@dls.net>
|
|
Subject: [PATCH] [ar6k] Build the wireless driver without DEBUG
- Remove DEBUG from the Makefile
- Do not send events through netlink to userspace. We might
need to reevaluate this. But we seem to use wireless_send_event
at the right places.
(SEND_EVENT_TO_APP)
- Do not report debug logs to apps
(REPORT_DEBUG_LOGS_TO_APP)
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
