| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
the KEY_PHONE is backwards. It returns up when pushed and down when
released. The following change fixes it:
Signed-off-by: Sean McNeil <sean@mcneil.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>
|
|
fix trailing whitespace and function args for suspend.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Subject: [PATCH] - add suspend/resume function of s3c24xx_hcd driver
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
|
|
--> (http://bugzilla.openmoko.org/cgi-bin/bugzilla/attachment.cgi?id=595&action=view)
fix resume of fbdev BZ#79
I played a bit with the fbdev resume. With this patch the neo doesn't get this
white screen on resume from console and from X.
Signed-off-by: Reddog <reddog@mastersword.de>
|
|
s3c2410_dma_request used to return 0 for OK and something else
for error, now it returns -ve error code or +ve dma channel index + flag
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
I don't know what device the symlink should be linked
against on GTA01, somebody that does know needs to edit
it in where it says "FIXME"... I think the supplied method
can work OK otherwise.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
struct input_dev in include/linux/input.h used to have a union
cdev which contained the associated device struct pointer. This
got simplified out in 2.6.25, so this patch removes cdev from
our drivers that used it before.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
GTA01 -only
Restore power button functionality after resume operation
Per Werner's suggestion, run the PMU interrupt handler immediately after resume
to clear/handle any pending interrupts from that device. This appears to
resolve the dead-powerbutton-after-resume problem. This is not well-tested;
need feedback to see if there are any side-effects or other problems.
From BZ 1313
Signed-off-by: Mike Wester <mwester@dis.net>
|
|
Make sure we can't lose a jack interrupt in debounce, despite it is
a one-in-a-million thing that just needs replug to clear
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
- 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>
|
|
to_bundle returned the wrong data. The platform_device is the
parent of the class_device used by the LED device class. Return
the correct class.
num_leds was not set to the correct number of registered LEDs. All
loops using num_leds (e.g. module unloading) were not executed at
all.
On removal of the module disable all LEDs.
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Currently we do not use the PWM code to drive the LEDS. We have enabled the PWM
for four timer sources but disable it only for three, fix that up.
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Signed-Off-By: Holger Freyther <zecke@openmoko.org>
|
|
Headphone jack detection is bouncy, it can trigger multiple interrupts
on insertion or removal. This patch adds a workqueue that waits out the
interrupt spew in 100ms units, and if it sees no more interrupts for 100ms
only then samples and reports the jack state. I was unable to get a bounce
after 20 or so tries after this.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Glamo "cmd mode" is modal, but nothing took care about locking.
Also cmd mode was entered recursively in rotate_lcd().
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
loglevl=9 can cause failure to init glamo-fb
problem seems to be too low timeout when text scrolling can
delay commandqueue going empty
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
see
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1288
|
|
Samsung SoC
Use this irq_to_gpio in the neo1973 keyboard driver
|
|
Signed-Off-by: Holger Freyther <zecke@openmoko.org>
|
|
Signed-Off-by: Holger Freyther <zecke@openmoko.org>
|
|
Signed-Off-by: Holger Freyther <zecke@openmoko.org>
|
|
GTA01_GPIO_AUX_KEY looks odd.
Signed-Off-by: Holger Freyther <zecke@openmoko.org>
|
|
From: Andy Green <andy@openmoko.com>
Sigend-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>
|
|
Hey,
the legacy application 'atd' from Russ Nelson/Nils Faerber, used by Qtopia, to
schedule alarms currently fails to start as the the above ioctl is failing.
The other drivers in drivers/rtc implement the above ioctl and we can
implement it too.
The code to mask/unmask the RTC alarm is copied from the set_alarm routine and
adapted to use the reg_set_bit_mask and reg_set_clear_mask.
It is compiling, so it must work. Please welcome me the lkml way ;)
Signed-Off-by: Holger Hans Peter Freyther <zecke@openmoko.org>
|
|
We don't take care to stop driving generated USB host power even
when we have a 1A charger connected on the same pins.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
Starting up all the PWMs seems to be needed for PWM3 operation
and FIQ / HDQ / VIB operation. But after starting, turn the
LEDs to GPIO-only.
Applies on top of Willie's patch
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
|
|
|
|
We need to be able to use the config option CONFIG_MMC_UNSAFE_RESUME that allows the rootfs
to live on SD. But when we use this, it tries to send a reset command to the SD card during
suspend -- and unfortunately many things like Power have suspended by then.
This patch again rejects IO on the MMC device during suspend of the MMC device, and it
gives the result the rootfs on SD card works okay.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
This is a driver for the bq27000 found in the Highcell A5
battery, and the platform device stuff for it for GTA02. It
is a Power Supply Class battery device.
The driver doesn't contain an HDQ engine but accepts pointers
from the platform data to the HDQ action routines; our
platform data plugs it into the FIQ HDQ engine stuff.
The Power Supply class exposes the battery down /sys so you
can find out battery status by doing the equivalent of this
bash command
for i in capacity charge_full current_now present status technology temp time_to_empty_now time_to_full_now type voltage_now ; do echo -n "$i " ; cat /sys/devices/platform/bq27000-battery.0/power_supply/bat/$i ; done
Here is the kind of result you get from a battery discharging
capacity 0
charge_full 1215585
current_now 183375
present 1
status Discharging
technology Li-ion
temp 276
time_to_empty_now 0
time_to_full_now 3932100
type Battery
voltage_now 2761000
Note that temp is in 1/10 degrees C, other values are in uV,
uA, uW. The time_to_* reported are bogus, but that is what
the battery actually reports.
We can make more mappings to entries in power_supply class
but this is enough to get started with.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
This adds a platform driver and device which performs HDQ
battery protocol using a single GPIO pin which is set
through platform data.
HDQ has some hard latency requirements which can't
be met if interrupts are enabled, so normally using
a GPIO for this will require blocking out all other
interrupts and processes for several milliseconds
per register being read or written.
This HDQ protocol engine is a FSM implemented inside the
the FIQ ISR and regulated by timer interrupts happening
at 20us intervals. The path through the FSM on any
"clock" is very short and should be over with in ~
1us. Because FIQ has guaranteed latencies of <1us,
it means we can service the HDQ protocol without
blocking interrupts or any other process other than
the caller that is waiting for the result. It's pretty
cool performance from 1 GPIO ;-)
Due to it being hard to do locking from the FIQ ISR
the code simply sleeps 10ms or whatever the scheduler
gives it and checks if the transfer took place yet.
This platform driver doesn't have any knowledge about
the device it is talking to, it just knows it is a
HDQ device. It exports three functions for read, write
and confirming HDQ is initialized. It also exports two
/sys nodes that are usable by humans, one dumps the whole
127 register HDQ register space
# cat /sys/devices/platform/gta02-hdq.0/hdq/dump
00 44 55 00 00 00 ba 04 a2 0d 50 00 00 00 00 00
00 00 9a 1a 00 00 ff ff ff ff 29 00 00 00 80 2b
00 00 00 00 00 00 ff ff 00 00 00 00 00 32 af 06
a0 d8 37 4e 00 00 00 00 00 00 00 34 2e 03 b4 e7
00 00 06 00 41 00 4c 02 00 00 00 00 00 00 00 00
83 02 00 00 94 09 59 b9 a5 0d 7f 21 00 00 7a ff
df ff 62 ff a7 04 2e 05 00 00 00 01 00 07 00 00
2a 78 36 67 7b b5 1b a9 af 19 38 89 63 57 42 7c
#
and the other allows to set one register
# echo 2 170 > /sys/devices/platform/gta02-hdq.0/hdq/write
writes 0xAA into register 2.
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
--- linux-2.6.22/drivers/i2c/chips/pcf50606.c.orig 2008-01-17 22:30:16.000000000 -0800
+++ linux-2.6.22/drivers/i2c/chips/pcf50606.c 2008-01-17 22:31:43.000000000 -0800
@@ -71,12 +71,19 @@
I2C_CLIENT_INSMOD_1(pcf50606);
-#define PCF50606_F_CHG_FAST 0x00000001 /* Charger Fast allowed */
-#define PCF50606_F_CHG_PRESENT 0x00000002 /* Charger present */
-#define PCF50606_F_CHG_FOK 0x00000004 /* Fast OK for battery */
-#define PCF50606_F_CHG_ERR 0x00000008 /* Charger Error */
-#define PCF50606_F_CHG_PROT 0x00000010 /* Charger Protection */
-#define PCF50606_F_CHG_READY 0x00000020 /* Charging completed */
+#define PCF50606_B_CHG_FAST 0 /* Charger Fast allowed */
+#define PCF50606_B_CHG_PRESENT 1 /* Charger present */
+#define PCF50606_B_CHG_FOK 2 /* Fast OK for battery */
+#define PCF50606_B_CHG_ERR 3 /* Charger Error */
+#define PCF50606_B_CHG_PROT 4 /* Charger Protection */
+#define PCF50606_B_CHG_READY 5 /* Charging completed */
+
+#define PCF50606_F_CHG_FAST (1<<PCF50606_B_CHG_FAST) /* Charger Fast allowed */
+#define PCF50606_F_CHG_PRESENT (1<<PCF50606_B_CHG_PRESENT) /* Charger present */
+#define PCF50606_F_CHG_FOK (1<<PCF50606_B_CHG_FOK) /* Fast OK for battery */
+#define PCF50606_F_CHG_ERR (1<<PCF50606_B_CHG_ERR) /* Charger Error */
+#define PCF50606_F_CHG_PROT (1<<PCF50606_B_CHG_PROT) /* Charger Protection */
+#define PCF50606_F_CHG_READY (1<<PCF50606_B_CHG_READY) /* Charging completed */
#define PCF50606_F_CHG_MASK 0x000000fc
#define PCF50606_F_PWR_PRESSED 0x00000100
@@ -1026,12 +1033,12 @@
static DEVICE_ATTR(chgmode, S_IRUGO | S_IWUSR, show_chgmode, set_chgmode);
static const char *chgstate_names[] = {
- [PCF50606_F_CHG_FAST] = "fast_enabled",
- [PCF50606_F_CHG_PRESENT] = "present",
- [PCF50606_F_CHG_FOK] = "fast_ok",
- [PCF50606_F_CHG_ERR] = "error",
- [PCF50606_F_CHG_PROT] = "protection",
- [PCF50606_F_CHG_READY] = "ready",
+ [PCF50606_B_CHG_FAST] = "fast_enabled",
+ [PCF50606_B_CHG_PRESENT] = "present",
+ [PCF50606_B_CHG_FOK] = "fast_ok",
+ [PCF50606_B_CHG_ERR] = "error",
+ [PCF50606_B_CHG_PROT] = "protection",
+ [PCF50606_B_CHG_READY] = "ready",
};
static ssize_t show_chgstate(struct device *dev, struct device_attribute *attr,
|
|
[ Stop kernel from hanging every once in a while during Glamo
initialization. ]
debug-glamo-fb-cmdqueue-wait-timeout.patch
From: warmcat <andy@warmcat.com>
|
|
|
|
This is a temporary work-around Mike Westerhof for this bug:
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=788
See also
http://lists.openmoko.org/pipermail/openmoko-kernel/2008-February/000804.html
(It's the 2nd option.)
We may settle on a different solution in the future, depending on
feedback from upstream.
|
|
|
|
|
|
S3C24xx ECC mis-calculates the bit to flip:
http://lists.infradead.org/pipermail/linux-mtd/2007-October/019586.html
If the error couldn't be corrected, we returned "no problem" :-(
http://lists.infradead.org/pipermail/linux-mtd/2007-October/019615.html
Signed-off-by: Werner Almesberger <werner@openmoko.org>
|
|
|
|
|
|
|
