Age | Commit message (Collapse) | Author |
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
On GTA02 we use FIQ to manage the vibrator IO now. That
is necessary because we stole timer3 from doing hw pwm
for vibrator. This keeps the same UI in /sys but does
"bitbang pwm" on the same vibrator GPIO
From: Andy Green <andy@openmoko.com>
Signed-off-by: Andy Green <andy@openmoko.com>
|
|
|
|
Disable the hardware ECC checking on S3C2440 based platforms (HXD8, SMDK2440,
GTA02) for the time being, since our u-boot doesn't yet support it for 2k page
size NAND
|
|
This patch disables the reporting of touchscreen-like devices via
/dev/input/mice. In the Neo1973 (much like other handheld devices),
we need this to distinguish between the touchscreen (which uses tslib)
and optional additional usb/bluetooth mice that might be attached.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
|
|
|
|
|
|
Moved shared PMU code from pcf50606.h and pcf50633.h (which prevented inclusion
of both at the same time) to pcf506xx.h
- include/linux/pcf50606.h (struct pmu_voltage_rail, enum pmu_event, pmu_cb):
moved to pcf506xx.h
- include/linux/pcf50633.h (struct pmu_voltage_rail, enum pmu_event, pmu_cb):
moved to pcf506xx.h
Signed off-by: Werner Almesberger <werner@openmoko.org>
|
|
|
|
|
|
This is a Linux driver for the STmicro LIS302DL 3-axis accelerometer.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
|
|
|
|
[ FIXME:
include/asm-arm/arch-s3c2410/irqs.h shouldn't contain device-specific
changes. ]
This is a Linux kernel driver for the Smedia Glamo336x / Glamo337x
multi-function peripheral device.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
|
|
|
|
This is a patch that seems to make the USB hangs on the S3C2440 go away. At
least a good amount of ping torture didn't make them come back so far.
The issue is that, if there are several back-to-back packets,
sometimes no interrupt is generated for one of them. This
seems to be caused by the mysterious dual packet mode, which
the USB hardware enters automatically if the endpoint size is
half that of the FIFO. (On the 2440, this is the normal
situation for bulk data endpoints.)
There is also a timing factor in this. I think what happens is
that the USB hardware automatically sends an acknowledgement
if there is only one packet in the FIFO (the FIFO has space
for two). If another packet arrives before the host has
retrieved and acknowledged the previous one, no interrupt is
generated for that second one.
However, there may be an indication. There is one undocumented
bit (none of the 244x manuals document it), OUT_CRS1_REG[1],
that seems to be set suspiciously often when this condition
occurs. There is also CLR_DATA_TOGGLE, OUT_CRS1_REG[7], which
may have a function related to this. (The Samsung manual is
rather terse on that, as usual.)
This needs to be examined further. For now, the patch seems to do the
trick.
Note that this is not a clean solution by any means, because we
might potentially get stuck in that interrupt for quite a while.
|
|
MTD: S3C24XX large page NAND support
This adds support for using large page NAND devices
with the S3C24XX NAND controller. This also adds the
file Documentation/arm/Samsung-S3C24XX/NAND.txt to
describe the differences.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
|
|
This is a MMC/SD driver for the Samsung S3C24xx SD/MMC controller, originally
developed years ago by Thomas Kleffel <tk@maintech.de>.
Due to time restraints, he had no time to further maintain the driver and
follow the mainline Linux changes in the SD/MMC stack.
With his authorization, I have taken over the task of making it compliant to
the current mainline SD/MMC API and take care of the mainline kernel merge.
After a potential kernel inclusion, we would co-maintain the driver.
Acked-by: Thomas Kleffel <tk@maintech.de>
Signed-off-by: Harald Welte <laforge@gnumonks.org>
|
|
Use FIC's own USB Vendor ID rather than NetChip's
Yes, we could solve this by some modprobe.conf parameters, but I'd like to
rather not rely on this.
|
|
|
|
We need this stupid workaround since our amplifier chip uses a 'reserved' I2C
address
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
|
|
This is a backlight driver for the FIC/OpenMoko Neo1973 GTA01 GSM Phone
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
This patch adds driver support for the vibator device of the FIC/OpenMoko
Neo1973 GSM phone. The driver uses the existing LED class driver framework,
since there's a lot of similarity between the LED and the vibrator function.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
This provides support for the GTA01 keyboard
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
This driver adds support for the SPI-based control interface of the LCM (LCD
Panel) found on the FIC GTA01 hardware.
The specific panel in this hardware is a TPO TD028TTEC1, but the driver should
be able to drive any other diplay based on the JBT6K74-AS controller ASIC.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
This is a NXP PCF50606 power management unit driver.
The PCF50606 is used in the FIC/OpenMoko Neo1973 GTA01 GSM phone.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
[PATCH] Add Kconfig option to enable NAND bad-block-table support for s3c2410
This patch adds a new CONFIG_MTD_NAND_S3C2410_BBT which, if enabled,
asks the mtd NAND core to use a bad-block table.
Signed-off-by: Harald Welte <laforge@openmoko.org>
|
|
fix-i2c-s3c2410-resume-race.patch
There is a nasty race between i2c-s3c2410 resume and resume of I2C
driver and the client drivers -- the watchdog device actually gets to
use the dead I2C bus before it is reinitialized by the I2C driver
resume! This patch makes sure any customers get turned away until
the shopkeeper has woken up.
Signed-off-by: Andy Green <andy@openmoko.com>
|