| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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] [bq27000] Make the checkpatch.pl happy
|
|
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>
|
|
|
|
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.
|
|
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>
|
|
Disable pcf interrupt (not for wake, just as interrupt) in
suspend, re-enable it again just before we force-call the
workqueue function at end of pcf resume, which leads to
pcf interrupt source registers getting cleared so it can
signal an interrupt normally again.
This change ends the uncontrolled appearance of pcf interrupts
during resume time which previously caused the work to attempt
to use the I2C stuff before i2c host device had itself resumed.
Now the isr work is only queued, and the isr work function called,
definitively after pcf resume completes.
In suspend time, the work function may have been queued some
time before and be pending, and it could still show up at a
bad time. Therefore if the work function sees that it is
coming since the start of pcf50633 suspend function, it
aborts without attempting to read the pcf interrupt regs,
leaving them for resume to take care of.
USB current limit and no battery work functions are also made
aware of suspend state and act accordingly.
Lastly I noticed that in early resume, i2c_get_clientdata(&pcf->client)
returns NULL, presumably because i2c device is still suspended. This
could easily make trouble for async events like interrupt work,
since pcf pointer is the client data. Disabling appearance of the
work until after pcf50633 resume will also avoid that.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Use an enum to define pcf50633 suspend / resume state.
Add PCF50633_SS_RESUMING_BUT_NOT_US_YET to be the state
early in resume: add platform driver resume function just
to set this state so we can differentiate between early
resume and late suspend.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
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>
|
|
Sean McNeil reports that he doesn't get pcf50633 interrupts any
more after resume. This adds back the call to ISR work in
the resume, removal of which is probably to do with 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>
|
