[Zaurus-devel] 3.0-rc1: alsactl restore fails on spitz
Hi Something changed in ALSA land, if you use sound you may want to check. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] spitz pm: adjust messages
Charger error is something that should be reported to the syslog; do
it. If temperature reading fails, we do not want to charge the
battery, anyway.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 785880f..513588c 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -317,6 +302,8 @@ static void sharpsl_charge_off(void)
static void sharpsl_charge_error(void)
{
+ dev_warn(sharpsl_pm.dev, Charger Error\n);
+
sharpsl_pm_led(SHARPSL_LED_ERROR);
sharpsl_pm.machinfo-charge(0);
sharpsl_pm.charge_mode = CHRG_ERROR;
@@ -513,8 +500,10 @@ static int sharpsl_check_battery_temp(void)
val = get_select_val(buff);
dev_dbg(sharpsl_pm.dev, Temperature: %d\n, val);
- if (val sharpsl_pm.machinfo-charge_on_temp) {
- printk(KERN_WARNING Not charging: temperature out of
limits.\n);
+ /* FIXME: this should catch battery read errors, but we should
+ probably avoid charging in 0C temperatures, too. */
+ if ((val 0) || (val sharpsl_pm.machinfo-charge_on_temp)) {
+ dev_warn(sharpsl_pm.dev, Not charging: temperature %d out of
limits.\n, val);
return -1;
}
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] spitz pm: add power monitoring driver
This adds battery/charge monitoring driver for spitz.
This is still not 100% done; spitz.c parts need small cleanups to fit
with the rest of code, and limit interface needs to be done.
Question is... who merges this when its done? Would it be ok to go
through PXA tree?
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 01c5769..5bf7f0e 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -921,6 +921,15 @@ static inline void spitz_i2c_init(void) {}
#endif
/**
+ * Battery
+
**/
+
+static struct platform_device spitz_battery_device = {
+ .name = spitz-battery,
+ .id = -1,
+};
+
+/**
* Machine init
**/
static void spitz_poweroff(void)
@@ -968,6 +977,7 @@ static void __init spitz_init(void)
spitz_nor_init();
spitz_nand_init();
spitz_i2c_init();
+ platform_device_register(spitz_battery_device);
}
static void __init spitz_fixup(struct machine_desc *desc,
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 52a462f..df54d70 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -102,6 +102,12 @@ config BATTERY_COLLIE
Say Y to enable support for the battery on the Sharp Zaurus
SL-5500 (collie) models.
+config BATTERY_SPITZ
+ tristate Sharp SL-3000C (spitz) battery
+ help
+ Say Y to enable support for the battery on the Sharp Zaurus
+ SL-3000C (spitz) models.
+
config BATTERY_WM97XX
bool WM97xx generic battery driver
depends on TOUCHSCREEN_WM97XX=y
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 8385bfa..7a82c1e 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
obj-$(CONFIG_BATTERY_COLLIE) += collie_battery.o
+obj-$(CONFIG_BATTERY_SPITZ)+= spitz_battery.o
obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
obj-$(CONFIG_BATTERY_BQ20Z75) += bq20z75.o
obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
diff --git a/drivers/power/spitz_battery.c b/drivers/power/spitz_battery.c
new file mode 100644
index 000..a612ff8
--- /dev/null
+++ b/drivers/power/spitz_battery.c
@@ -0,0 +1,318 @@
+/*
+ * Battery and Power Management code for the Sharp SL-3000c
+ *
+ * Copyright (c) 2009 Pavel Machek pa...@ucw.cz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include linux/platform_device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/power_supply.h
+#include linux/delay.h
+#include linux/spinlock.h
+#include linux/interrupt.h
+#include linux/gpio.h
+
+#include asm/mach-types.h
+#include mach/spitz.h
+#include mach/sharpsl_pm.h
+
+extern struct sharpsl_pm_status sharpsl_pm;
+
+struct spitz_bat {
+ struct power_supply psy;
+
+ bool (*is_present)(struct spitz_bat *bat);
+};
+
+static struct spitz_bat spitz_bat_main, spitz_ac;
+
+extern int sharpsl_pm_pxa_read_max(int channel);
+
+
+static int spitz_bat_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ int ret = 0;
+ struct spitz_bat *bat = container_of(psy, struct spitz_bat, psy);
+
+ val-intval = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_HEALTH:
+ /* POWER_SUPPLY_HEALTH_OVERHEAT , POWER_SUPPLY_HEALTH_COLD,
+ POWER_SUPPLY_HEALTH_OVERVOLTAGE,
POWER_SUPPLY_HEALTH_UNSPEC_FAILURE, POWER_SUPPLY_HEALTH_GOOD
+*/
+ return 0;
+ case POWER_SUPPLY_PROP_CHARGE_TYPE:
+ val-intval = POWER_SUPPLY_CHARGE_TYPE_NONE;
+ if (gpio_get_value(SPITZ_GPIO_CHRG_ON) == 0) {
+ if (gpio_get_value(SPITZ_GPIO_JK_B) == 1)
+ val-intval = POWER_SUPPLY_CHARGE_TYPE_FAST;
+ else
+ val-intval = POWER_SUPPLY_CHARGE_TYPE_TRICKLE;
+ }
+ return 0;
+ case POWER_SUPPLY_PROP_STATUS:
+ {
+ int status = 0;
+
+ if (gpio_get_value(SPITZ_GPIO_CHRG_ON) == 0)
+ printk(Chrg bit on. );
+ if (gpio_get_value(SPITZ_GPIO_JK_B) == 0)
+ printk(Slow charge bit on. );
+
+ val-intval = POWER_SUPPLY_STATUS_UNKNOWN
Re: [Zaurus-devel] Disable CF during suspend
Hi! Disable SPITZ_SCP_CF_POWER during suspend. Otherwise it eats battery, fast. Thanks to Stanislav Brabec. If you can verify that your card turns off on suspend, then you have my: Acked-by: Stanislav Brabec u...@penguin.cz Yes, I checked the LEDs to make sure it is off. It is. But I would line to see more aggressive power control, something like spitz_card_pwr_ctrl() in old kernels - if there is no CF and no (external) CF card inserted, then SPITZ_SCP_CF_POWER card be turned off. If they are memory cards, they can be turned off even while idle. Yes, that would be nice; but this is already good first step. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Zaurus GPIO buttons with matrix keypad drivers
Hi! following comments from a Stanislav patch Spitz switched to generic matrix-gpio keyboard driver in 2.6.32-rc0, but that means that support for power button and lid switches was lost. This restores it, using button-gpio code. in the 2.6.38 source I only find in spitz.c: #if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE) static struct gpio_keys_button spitz_gpio_keys[] and in tosa.c : static struct gpio_keys_button tosa_gpio_keys[] What about the rest of Zaurus? Well, it probably needs similar patches It should not be hard to copy from spitz. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] latest angstrom image + linux-2.6.38.4 report
Hi! In general, defconfig in OE is very poor (missing support for some parts of the hardware and many important USB devices). Here are my configs: http://www.penguin.cz/~utx/zaurus/feed/images/spitz/ (My fresh configs will always appear here after some testing.) sorry to hear that...I'm trying to follow the abandoned models an did not test the producton kernel enough, only the kexecboot version (and that's not too bad ;) Yes, with exception of charging, battery discharging during suspend and the missing HDD LED support, 2.6.38.4 works well. I got WLAN working, On recent vanilla kernels, I noticed CF card is still powered up during suspend (it has a LED...). Additional thing... if machine is suspended, then plugged into AC power, it apparently dies. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] latest angstrom image + linux-2.6.38.4 report
Hi! I just tested the latest angstrom image (built by myself). I seen following regressions in comparison with 2.6.26: - While booting from SD card, I seen kernel panic several times, but did not have serial cable attached. I am not able to reproduce it any more, even if I try to do the same. I only remember mmc_blk_issue_rw_rq at the end of the screen. Did anybody else seen it. Usually issues only booting from CF. IIRC spitz crashes on first reboot after kernel flashing if power cable is attached ?? Well, my home built USB cable to 500mA USB was attached. I tested it later on battery or original power supply. Yes, it may be a reason of these crashes. I'll retry with the weak USB power plug. (I never seen weak-power-supply-crash with 2.6.26-RP). Yes, it is probably software problem. BTW online charging does not work _at all_. Connected with empty battery to (hopefully good) power supply at 10pm, battery was still empty at 7am :-(. - HDD LED seems to not work. Hdd not yet tested HDD works, just the LED does not. Tested with the OE kernel. I'll retry with my custom .config file. It also enables more USB drivers. I'm using old driver, LED works there. What do I need to change to get new one? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [RFC PATCH v2 1/3] PM / Core: suspend_again callback for device PM.
Hi! too heavy (in fact it's much lighter weight than resuming all devices that your approach doesn't prevent from happening, so for example on my desktop/notebook machines I woulnd't mind at all if user space were thawed after all of the devices had been resumed). Well, it would be behavior change for the user. I told the zaurus to go s2ram, I do not expect it to wake up after 5 minutes because it needed to check battery status. I'd have to modify my userland to retry suspend again and again and again... And that's exactly what should be done. Have a user space process controlling that, because avoiding to thaw user space doesn't buy us almost anything. That makes Zaurus implement different user-kernel interface than PC class machine, because of hardware quirk. Now, I know that it's probably easier to modify the kernel than to write a user space tool for that, test it and so on, but easier is not necessarily better. It is easier, allows us to keep same user-kernel interface on PC and Zaurus, and is compatible with 2.6.38. Heck, I'm used to typing echo mem /sys/power/state. I should not have to learn different interface just because Zaurus does not have proper hardware charger. I'm not sure if we need to cover hibernation. Do you know any machine that needs this for hibernation case? Yes, any machine that needs it while suspended. What's the difference, after all? The only difference is that there's an image on permanent storage in the hibernation case. You still can overheat a battery when charging it while hibernated, right? No, you can not; not on Zaurus. It can not really power down; it is always sleeping. s2ram is sleep in operating system, hibernation or poweroff is sleep in bootloader. Bootloader takes care of battery in that case. To conclude, I'm not sure about the approach. In particular, I'm not sure if the benefit is worth the effort and the resulting complications (ie. the possibility of having to deal with wakeup signals not requested by user space) seem to be a bit too far reaching. We already have platform-specific hacks to do exactly this at least on Zaurus. Moving it to common code means that hacks are not duplicated.. Well, good to know they are there, but I'm still not sure what to do about that. At the moment I feel like having too little information to really decide, so perhaps please point me to the code you're talking about for starters. Ok, see the spitz_should_wakeup() function in arch/arm/mach-pxa/* and should_wakeup() usage. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [RFC PATCH v2 1/3] PM / Core: suspend_again callback for device PM.
Hi! And that's exactly what should be done. Have a user space process controlling that, because avoiding to thaw user space doesn't buy us almost anything. That makes Zaurus implement different user-kernel interface than PC class machine, because of hardware quirk. Let me say that again: If Zaurus needs to resume everything except for user space periodically to monitor the battery charger, I'm not sure if our suspend interface is the right one for it in the first place. Well, Zaurus does not need to resume everything. SPI+charger code is enough, and that would be preffered. No need to touch disk etc. It seriously looks like a workaround for the lack of appropriately implemented runtime PM, just like the Android's opportunistic suspend. No, not really. I'm running standard Debian; I do not want/need anything like opportunistic suspend. Now, I know that it's probably easier to modify the kernel than to write a user space tool for that, test it and so on, but easier is not necessarily better. It is easier, allows us to keep same user-kernel interface on PC and Zaurus, and is compatible with 2.6.38. Heck, I'm used to typing echo mem /sys/power/state. I should not have to learn different interface just because Zaurus does not have proper hardware charger. No, this interface should not be used on Zaurus at all. It's not mean for that and while you can hack it to kind of work, it still is hacking rather than designing things. Why not? I want the Zaurus to sleep. Why should I have to know how its charging unit works? Why should I use different interface than on PC? I want it to suspend, put it into backpack and move... Bootloader takes care of battery in that case. So the difference is that we let someone else worry. Cool. :-) Yes. Ok, see the spitz_should_wakeup() function in arch/arm/mach-pxa/* and should_wakeup() usage. OK, I will. Thanks. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] zaurus: mmcblk0: error -110
On Tue 2011-04-12 17:52:17, Cyril Hrubis wrote: Hi! Which model do you have? And check the corresponding board file if card detect GPIO handling is doing right. I've got spitz (SL-3200). So I suppose the board file is arch/arm/mach-pxa/spitz.c, I'll have a look. Hmm, besides cleanup by Marek Vasut there were no changes in the code. And it seems that it was just cleanup in spitz_card_pwr_ctrl(). With vanilla 2.6.38, I observe similar problem. MMC removal is not detected; I get error -110 whilst initalising SD card on reinsert. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] 8250 vs pxa_serial (was Re: pxa27x/spitz: serials in recent kernels)
Hi! I cculd not get serial port to work in recent kernels (2.6.35 was oldest I tried). I know they are little used but still very useful for debugging. Is there some special config that needs to be done? Pavel I have output on ttyS0 using the Sharp cable, never had issues. Remember that bootloader is 9600n8 while kernels are usually 115200n8. Ok, I know what is going on. I need both PXA_SERIAL and 8250... and these two don't go well together. I tried: CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set CONFIG_SERIAL_8250_CS=y CONFIG_SERIAL_8250_NR_UARTS=1 CONFIG_SERIAL_8250_RUNTIME_UARTS=0 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # # CONFIG_SERIAL_MAX3100 is not set # CONFIG_SERIAL_MAX3107 is not set CONFIG_SERIAL_PXA=y CONFIG_SERIAL_PXA_CONSOLE=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y (BTW should 8250_RUNTIME_UARTS be called boottime uarts? That's what help says). ...but no luck. As soon as I enable 8250, pxa serials stop working :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] 2.6.39-rc2 on zaurus: does not build, does not boot
Hi!
Build fix is below. Maybe it is pending in the trees somewhere
already...
Boot stops just after mounting root filesystem; cursor stops
flashing. (Any idea what goes on there?)
Pavel
--- ./drivers/video.ofic/pxafb.c2011-04-06 15:19:51.0 +0200
+++ ./drivers/video/pxafb.c 2011-04-07 06:20:20.0 +0200
@@ -1648,7 +1648,7 @@
switch (val) {
case CPUFREQ_PRECHANGE:
- if (!fbi-overlay[0].usage !fbi-overlay[1].usage)
+// if (!fbi-overlay[0].usage !fbi-overlay[1].usage)
set_ctrlr_state(fbi, C_DISABLE_CLKCHANGE);
break;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] pxa27x/spitz: serials in recent kernels
Hi! I cculd not get serial port to work in recent kernels (2.6.35 was oldest I tried). I know they are little used but still very useful for debugging. Is there some special config that needs to be done? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] zaurus bluetooth regression
Hi! It seems this commit commit 7a56aa45982bb87bfca98a2832b5ae782c03364a ... ...is responsible for my bluetooth problems on zaurus -- at least bisect pointed to it, as I use 16C950-based bluetooth card, it seems very logical. I'll try 2.6.37-rc8 with that patch reverted... And yes, 37-rc8 with that reverted results in working bluetooth, so yrs, that patch is responsible. could you tell, what kind of problem you're encountering and if you could tell, which flag UART_CAP_EFR or UART_CAP_SLEEP causes the problem? Bluetooth will not work with 'tx command timeout', details should be in bugzilla. CAP_EFR seems to cause the problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] zaurus bluetooth regression
Hi!
It seems this commit
commit 7a56aa45982bb87bfca98a2832b5ae782c03364a
...
...is responsible for my bluetooth problems on zaurus -- at least
bisect pointed to it, as I use 16C950-based bluetooth card, it seems
very logical. I'll try 2.6.37-rc8 with that patch reverted...
And yes, 37-rc8 with that reverted results in working bluetooth, so
yrs, that patch is responsible.
Pavel
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 09ef570..bc8ed4b 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -241,7 +241,7 @@ static const struct serial8250_config uart_config[] = {
.fifo_size = 128,
.tx_loadsz = 128,
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
- .flags = UART_CAP_FIFO,
+ .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
},
[PORT_16654] = {
.name = ST16654,
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] zaurus bluetooth regression
Hi!
It seems this commit
commit 7a56aa45982bb87bfca98a2832b5ae782c03364a
Author: Yegor Yefremov yegor_s...@visionsystems.de
Date: Wed Jun 16 16:29:55 2010 +0200
serial: add UART_CAP_EFR and UART_CAP_SLEEP flags to 16C950 UARTs
definition
Adding UART_CAP_EFR and UART_CAP_SLEEP flags will enable sleep
mode
and automatic CTS flow control for 16C950 UARTs. It will also
avoid
capabilities detection warning like this:
ttyS0: detected caps 0700 should be 0100
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
...is responsible for my bluetooth problems on zaurus -- at least
bisect pointed to it, as I use 16C950-based bluetooth card, it seems
very logical. I'll try 2.6.37-rc8 with that patch reverted...
See https://bugzilla.kernel.org/show_bug.cgi?id=17061 .
Pavel
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index 09ef570..bc8ed4b 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -241,7 +241,7 @@ static const struct serial8250_config uart_config[] = {
.fifo_size = 128,
.tx_loadsz = 128,
.fcr= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
- .flags = UART_CAP_FIFO,
+ .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP,
},
[PORT_16654] = {
.name = ST16654,
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] zaurus spitz 2.6.3* .config
On Thu 2010-10-28 15:20:15, Franck L wrote: Hi Pavel :) Thank you for your config :) but as in this post where you already proposed it ( http://lists.linuxtogo.org/pipermail/zaurus-devel/2010-May/000304.html ) i wasn't able to find your config... where was it ? I did not actually attach it this time. I see you got it working; if you still want my config, let me know. Pavel Have a nice day ! Franck On Tue, Oct 26, 2010 at 09:36:05AM +0200, Pavel Machek wrote : Hi! i actually trying to create a debian system for my borzoi. since the rootfs from which i start is old (created with a kernel 2.6.24), trying to upgrade the sid system leads to a problem with udev (needs at least kernel 2.6.26). i try creating .config for 2.6.27.54 and 2.6.36 kernel. for the moment, both fails (dmesg from load with the 2.6.27.54 : http://pastebin.com/MCxK8akv: seems that there is a problem with i2c...) for 2.6.36 i builded, nothing starts but the harddrive (?) which i may hear turn, but the screen doesn't up, nothing seems to respond. i may provide you my buggy .config, but i think there is no interest. tell me if you want. so, i wondered if you could give me one of your last .config for the latest kernel that works, in order that i could try to create a debian environment for my zaurus. I can provide you with spitz config; it works, modulo wifi... No borzoi here... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] zaurus spitz 2.6.3* .config
Hi! i actually trying to create a debian system for my borzoi. since the rootfs from which i start is old (created with a kernel 2.6.24), trying to upgrade the sid system leads to a problem with udev (needs at least kernel 2.6.26). i try creating .config for 2.6.27.54 and 2.6.36 kernel. for the moment, both fails (dmesg from load with the 2.6.27.54 : http://pastebin.com/MCxK8akv: seems that there is a problem with i2c...) for 2.6.36 i builded, nothing starts but the harddrive (?) which i may hear turn, but the screen doesn't up, nothing seems to respond. i may provide you my buggy .config, but i think there is no interest. tell me if you want. so, i wondered if you could give me one of your last .config for the latest kernel that works, in order that i could try to create a debian environment for my zaurus. I can provide you with spitz config; it works, modulo wifi... No borzoi here... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Zaurus driver being loaded when it shouldn't.
Hi! I have a Dell Adamo laptop which has a wwan device which is triggering zaurus.ko to get loaded, probably due to this wildcard match.. alias: usb:v*p*d*dc*dsc*dp*ic02isc0Aip00* Full lsusb -v is at http://davej.fedorapeople.org/usb Unfortunately, I don't use usb device mode on zaurus, but hopefully someone on zaurus list does, and can provide lsusb... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] pxa pcmcia timings
Hi!
I used to delve into zaurus code for awhile ago. There are some local changes
left from that time.
One thing is the change to pxa pcmcia timings.
Here's the original code from 2.6.16:
static inline u_int pxa2xx_mcxx_hold(u_int pcmcia_cycle_ns,
u_int mem_clk_10khz)
{
u_int code = pcmcia_cycle_ns * mem_clk_10khz;
return (code / 30) + ((code % 30) ? 1 : 0) - 1;
}
static inline u_int pxa2xx_mcxx_asst(u_int pcmcia_cycle_ns,
u_int mem_clk_10khz)
{
u_int code = pcmcia_cycle_ns * mem_clk_10khz;
return (code / 30) + ((code % 30) ? 1 : 0) - 1;
}
static inline u_int pxa2xx_mcxx_setup(u_int pcmcia_cycle_ns,
u_int mem_clk_10khz)
{
u_int code = pcmcia_cycle_ns * mem_clk_10khz;
return (code / 10) + ((code % 10) ? 1 : 0) - 1;
}
I don't know the original reasons why the timings are calculated in this way.
My guess that it's sa1100 adapted to pxa. But the pxa has more control of the
bus cycle. After looking at pxa docs and CF/PCMCIA standard I've changed
the formula to the following:
static inline u_int pxa2xx_mcxx_hold(u_int hold,
u_int mem_clk_10khz)
{
u_int code = hold * mem_clk_10khz;
return (code / 10) + ((code % 10) ? 1 : 0);
}
static inline u_int pxa2xx_mcxx_asst(u_int cas,
u_int mem_clk_10khz)
{
u_int code = cas * mem_clk_10khz;
if(code % 30 20) return code/30;
else return code/30-1;
}
static inline u_int pxa2xx_mcxx_setup(u_int set,
u_int mem_clk_10khz)
{
u_int code = set * mem_clk_10khz;
return (code / 10) + ((code % 10) ? 1 : 0) - 2;
}
The functions above take specific time as a parameter, not the whole cycle
length.
For example, pxa2xx_pcmcia_set_mcio looked like this:
static int pxa2xx_pcmcia_set_mcio( int sock, int speed, int clock )
{
u_int set, cas, hold;
if(speed == 255) {
set = 70;
hold = 20;
cas = 165;
Although I can't guarantee that my calculations are correct, it worked with
all of my CF cards on c3000.
If anyone is interested, I can prepare the patch.
Yes, patch would be nice. I am currently debugging some PCMCIA
problems... Question: is/was there situation where your version worked
but old one did not? Does it provide faster data rates?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] 2.6.36-rc1 on zaurus: bluetooth regression
Hi! Good news is that it boots, suspends and resumes. Bad news is that bluetooth broke for me. I'm using CF bluetooth card. Socket 0 Bridge:[pxa2xx-pcmcia] (bus ID: pxa2xx-pcmcia) Configuration: state: on ready: yes Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V Socket 0 Device 0: [serial_cs] (bus ID: 0.0) Configuration: state: on Product Name: Compact Flash Bluetooth Card Identification: manf_id: 0x0279 card_id: 0x950b function: 2 (serial) prod_id(1): Compact Flash (0x95521410) prod_id(2): Bluetooth Card (0x7664fb1d) prod_id(3): --- (---) prod_id(4): --- (---) Socket 1 Bridge:[pxa2xx-pcmcia] (bus ID: pxa2xx-pcmcia) Configuration: state: on ready: yes Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V Socket 1 Device 0: [ide-cs](bus ID: 1.0) Configuration: state: on Product Name: HITACHI microdrive Identification: manf_id: 0x0319 card_id: 0x function: 4 (fixed disk) prod_id(1): HITACHI (0xf4f43949) prod_id(2): microdrive (0xa6d76178) prod_id(3): --- (---) prod_id(4): --- (---) In 2.6.35, I have lots of messages in the syslog, and speed is slow, but it works. Aug 19 08:01:06 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3 expected 2 Aug 19 08:01:06 toy kernel: bcsp_recv: Out-of-order packet arrived, got 4 expected 2 Aug 19 08:01:11 toy kernel: bcsp_recv: Short BCSP packet Aug 19 08:01:11 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3 expected 2 Aug 19 08:01:11 toy kernel: bcsp_recv: Out-of-order packet arrived, got 4 expected 2 Aug 19 08:01:12 toy kernel: bcsp_recv: Out-of-order packet arrived, got 5 expected 2 Aug 19 08:01:16 toy kernel: bcsp_recv: Short BCSP packet Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet arrived, got 2 expected 1 Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet arrived, got 3 expected 1 Aug 19 08:01:16 toy kernel: bcsp_recv: Out-of-order packet arrived, got 4 expected 1 In 2.6.36-rc1, I get: Aug 20 08:38:27 toy bluetoothd[1318]: HCI dev 0 down Aug 20 08:38:27 toy bluetoothd[1318]: Adapter /org/bluez/1318/hci0 has been disabled Aug 20 08:38:27 toy bluetoothd[1318]: Stopping security manager 0 Aug 20 08:38:27 toy kernel: pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0 Aug 20 08:38:27 toy kernel: PM: Removing info for pcmcia:0.0 Aug 20 08:38:27 toy kernel: PM: Removing info for No Bus:ttyS0 Aug 20 08:38:27 toy bluetoothd[1318]: HCI dev 0 unregistered Aug 20 08:38:27 toy bluetoothd[1318]: Unregister path: /org/bluez/1318/hci0 Aug 20 08:38:27 toy kernel: PM: Removing info for No Bus:hci0 Aug 20 08:38:27 toy kernel: PM: Adding info for No Bus:ttyS0 Aug 20 08:38:31 toy kernel: pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 Aug 20 08:38:31 toy kernel: pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 201) Aug 20 08:38:31 toy kernel: PM: Adding info for pcmcia:0.0 Aug 20 08:38:31 toy kernel: PM: Removing info for No Bus:ttyS0 Aug 20 08:38:31 toy kernel: 0.0: ttyS0 at I/O 0xc48402f8 (irq = 201) is a 16C950/954 Aug 20 08:38:31 toy kernel: PM: Adding info for No Bus:ttyS0 Aug 20 08:38:36 toy bluetoothd[1318]: HCI dev 0 registered Aug 20 08:38:36 toy kernel: PM: Adding info for No Bus:hci0 Aug 20 08:38:36 toy kernel: bcsp_recv: Out-of-order packet arrived, got 1 expected 0 Aug 20 08:38:37 toy bluetoothd[1318]: accept: Socket operation on non-socket (88) Aug 20 08:38:37 toy bluetoothd[1318]: HCI dev 0 up Aug 20 08:38:37 toy bluetoothd[1318]: Starting security manager 0 Aug 20 08:38:37 toy kernel: bcsp_recv: Short BCSP packet Aug 20 08:38:39 toy kernel: PM: Removing info for No Bus:rfcomm1 Aug 20 08:38:39 toy kernel: PM: Adding info for No Bus:rfcomm1 Aug 20 08:38:40 toy pand[1546]: Bluetooth PAN daemon version 4.66 Aug 20 08:38:40 toy pand[1546]: Connecting to 00:21:BA:FF:2D:37 Aug 20 08:38:40 toy kernel: hci_cmd_task: hci0 command tx timeout Aug 20 08:38:42 toy bluetoothd[1318]: Can't read version info for /org/bluez/1318/hci0: Connection timed out (110) Aug 20 08:38:44 toy modprobe: FATAL: Could not load /lib/modules/2.6.36-rc1/modules.dep: No such file or directory Any ideas? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] zaurus battery patches
Hi!
...they certainly need more work. .7. version is newer but incomplete.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--- ./drivers/power.ofic/Makefile 2009-10-06 13:51:29.0 +0200
+++ ./drivers/power/Makefile 2009-10-11 16:12:09.0 +0200
@@ -24,6 +24,7 @@
obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
obj-$(CONFIG_BATTERY_TOSA) += tosa_battery.o
+obj-m += spitz_battery.o
obj-$(CONFIG_BATTERY_WM97XX) += wm97xx_battery.o
obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
diff -ur ./drivers/power.ofic/power_supply_sysfs.c ./drivers/power/power_supply_sysfs.c
--- ./drivers/power.ofic/power_supply_sysfs.c 2009-10-06 13:51:29.0 +0200
+++ ./drivers/power/power_supply_sysfs.c 2009-10-15 05:45:46.0 +0200
@@ -39,7 +39,8 @@
static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
static char *status_text[] = {
Unknown, Charging, Discharging, Not charging, Full
};
@@ -135,7 +136,8 @@
static ssize_t power_supply_show_static_attrs(struct device *dev,
struct device_attribute *attr,
- char *buf) {
+ char *buf)
+{
static char *type_text[] = { Battery, UPS, Mains, USB };
struct power_supply *psy = dev_get_drvdata(dev);
diff -ur ./drivers/power.ofic/spitz_battery.c ./drivers/power/spitz_battery.c
--- ./drivers/power.ofic/spitz_battery.c 2009-10-11 16:14:11.0 +0200
+++ ./drivers/power/spitz_battery.c 2009-10-22 07:27:52.0 +0200
@@ -0,0 +1,430 @@
+/*
+ * Battery and Power Management code for the Sharp SL-3000c
+ *
+ * Copyright (c) 2009 Pavel Machek pa...@ucw.cz
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Li-ion batteries are angry beasts, and they like to explode.
+ * If angry lithium comes your way, the hw was misdesigned.
+ *
+ */
+#include linux/platform_device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/power_supply.h
+#include linux/delay.h
+#include linux/spinlock.h
+#include linux/interrupt.h
+#include linux/gpio.h
+
+#include asm/mach-types.h
+#include mach/spitz.h
+#include mach/sharpsl.h
+#include mach/sharpsl_pm.h
+
+#include ../../arch/arm/mach-pxa/sharpsl.h
+
+extern struct sharpsl_pm_status sharpsl_pm;
+
+
+struct spitz_bat {
+ struct power_supply psy;
+
+ bool (*is_present)(struct spitz_bat *bat);
+};
+
+static struct spitz_bat spitz_bat_main, spitz_ac;
+
+extern int sharpsl_pm_pxa_read_max(int channel);
+
+int basic_current = 125; /* miliAmp */
+int battery_resistance = 422; /* miliOhm */
+
+/* 422 seems to be suitable for very old, 1Ah battery.
+ 2Ah battery probably has better resistance */
+
+/* Unfortunately, resistance depends on state of charge, current
+ * direction and temperature.
+ *
+ * Ouch, and dependency is actually _not_ too simple. It is lowest
+ * at 3.55V, very slowly rises at 4V (approximately linear dependency),
+ * and quickly rises towards 3.2V (in something exponential-looking).
+ *
+ * It is about same at 25Celsius and 40Celsius, and about 2.5x the value
+ * on 0Celsius, rising _very_ sharply.
+ *
+ * Li-ion should only be charged between 0 and 45 Celsius, and discharged
+ * between -20 and 60 celsius.
+ */
+
+extern int backlight_current;
+
+int battery_current(void)
+{
+ int intensity = sharpsl_pm.machinfo-backlight_get_status ? sharpsl_pm.machinfo-backlight_get_status() : 0;
+
+ return basic_current + backlight_current;
+}
+
+int liion_internal_voltage(int voltage, int current_ma)
+{
+ return voltage + (battery_resistance * current_ma / 1000);
+}
+
+int liion_expected_voltage(int internal_voltage, int current_ma)
+{
+ return internal_voltage - (battery_resistance * current_ma / 1000);
+}
+
+/* returns mV */
+int liion_voltage(void)
+{
+ /* Thanks to Stanislav B. ADC has 3.3V as reference,
+ is connected to battery over 47kOhm,
+ and to ground over 100kOhm. */
+ return (sharpsl_pm.machinfo-read_devdata(SHARPSL_BATT_VOLT) * 147 * 33)/256;
+}
+
+/* See for example http://www.kokam.com/english/biz/rc.html for
+ * voltage/capacity characteristic. I assume it is going to be
+ * reasonably similar to li-ion used in collie.
+ *
+ */
+
+/*
+ { 420, 100 },
+ { 417, 95 }, means it will report 100% between 418 and 420
+ */
+
+struct battery_thresh battery_levels[] = {
+ { 3980, 100 },
+ { 3900, 95 },
+ { 3860, 90 },
+ { 3800, 85 },
+ { 3760, 80 },
+ { 3720, 74 },
+ { 3680, 69 },
+ { 3620, 65 },
+ { 3570, 59 },
+ { 3560, 55 },
+ { 3550, 48 },
+ { 3530, 45 },
+ { 3510, 39 },
+ { 3490, 33 },
+ { 3470, 29 },
+ { 3450, 23 },
+ { 3410, 16 },
+ {0, 0 },
+};
+
+int get_percentage(void)
+{
+ int i = ARRAY_SIZE(battery_levels
Re: [Zaurus-devel] [PATCH 1/2] pxa/spitz: Rework spitz
On Wed 2010-07-07 14:48:48, Marek Vasut wrote:
This huge patch mostly shuffles code. The spitz.c file contained terrible mess
and needed a cleanup, here it is:
1) Made every part modular, components are not built in if not selected.
2) Removed loads of preprocessor goo, mostly #ifdef MACH_AKITA #endif
and
similar code. The kernel size will grow by a few kb now, but the file is
much
more readable.
3) Reworked SD/CF power setting function and made it reentrant.
4) Add ISL6271A regulator support
5) Correctly register WM8750
Signed-off-by: Marek Vasut marek.va...@gmail.com
Big changes, but look ok. ACK.
arch/arm/mach-pxa/include/mach/spitz.h |2 -
arch/arm/mach-pxa/spitz.c | 475
2 files changed, 304 insertions(+), 173 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/spitz.h
b/arch/arm/mach-pxa/include/mach/spitz.h
index fa1998c..685749a 100644
--- a/arch/arm/mach-pxa/include/mach/spitz.h
+++ b/arch/arm/mach-pxa/include/mach/spitz.h
@@ -185,7 +185,5 @@
/*
* Shared data structures
*/
-extern struct platform_device spitzscoop_device;
-extern struct platform_device spitzscoop2_device;
extern struct platform_device spitzssp_device;
extern struct sharpsl_charger_machinfo spitz_pm_machinfo;
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index c1048a3..26791de 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -18,14 +18,15 @@
#include linux/gpio_keys.h
#include linux/gpio.h
#include linux/leds.h
-#include linux/mtd/physmap.h
#include linux/i2c.h
#include linux/i2c/pca953x.h
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/spi/corgi_lcd.h
+#include linux/mtd/physmap.h
#include linux/mtd/sharpsl.h
#include linux/input/matrix_keypad.h
+#include linux/regulator/machine.h
#include asm/setup.h
#include asm/mach-types.h
@@ -33,11 +34,9 @@
#include asm/mach/sharpsl_param.h
#include asm/hardware/scoop.h
-
#include mach/pxa27x.h
#include mach/pxa27x-udc.h
#include mach/reset.h
-#include plat/i2c.h
#include mach/irda.h
#include mach/mmc.h
#include mach/ohci.h
@@ -45,10 +44,15 @@
#include mach/pxa2xx_spi.h
#include mach/spitz.h
+#include plat/i2c.h
+
#include generic.h
#include devices.h
#include sharpsl.h
+/**
+ * Pin configuration
+
**/
static unsigned long spitz_pin_config[] __initdata = {
/* Chip Selects */
GPIO78_nCS_2, /* SCOOP #2 */
@@ -124,6 +128,11 @@ static unsigned long spitz_pin_config[] __initdata = {
GPIO1_GPIO | WAKEUP_ON_EDGE_FALL, /* SPITZ_GPIO_RESET */
};
+
+/**
+ * Scoop GPIO expander
+
**/
+#if defined(CONFIG_SHARP_SCOOP) || defined(CONFIG_SHARP_SCOOP_MODULE)
/*
* Spitz SCOOP Device #1
*/
@@ -182,43 +191,60 @@ struct platform_device spitzscoop2_device = {
.resource = spitz_scoop2_resources,
};
-#define SPITZ_PWR_SD 0x01
-#define SPITZ_PWR_CF 0x02
+static void __init spitz_scoop_init(void)
+{
+ platform_device_register(spitz_scoop1_device);
+
+ /* Akita doesn't have the second SCOOP chip */
+ if (!machine_is_akita())
+ platform_device_register(spitzscoop2_device);
+}
/* Power control is shared with between one of the CF slots and SD */
-static void spitz_card_pwr_ctrl(int device, unsigned short new_cpr)
+static void spitz_card_pwr_ctrl(uint8_t enable, uint8_t new_cpr)
{
- unsigned short cpr = read_scoop_reg(spitzscoop_device.dev, SCOOP_CPR);
+ unsigned short cpr;
+ unsigned long flags;
- if (new_cpr 0x0007) {
+ if (new_cpr 0x7) {
gpio_set_value(SPITZ_GPIO_CF_POWER, 1);
- if (!(cpr 0x0002) !(cpr 0x0004))
- mdelay(5);
- if (device == SPITZ_PWR_CF)
- cpr |= 0x0002;
- if (device == SPITZ_PWR_SD)
- cpr |= 0x0004;
- write_scoop_reg(spitzscoop_device.dev, SCOOP_CPR, cpr |
new_cpr);
- } else {
- if (device == SPITZ_PWR_CF)
- cpr = ~0x0002;
- if (device == SPITZ_PWR_SD)
- cpr = ~0x0004;
- if (!(cpr 0x0002) !(cpr 0x0004)) {
- write_scoop_reg(spitzscoop_device.dev, SCOOP_CPR,
0x);
- mdelay(1);
- gpio_set_value(SPITZ_GPIO_CF_POWER, 0);
- } else {
- write_scoop_reg(spitzscoop_device.dev, SCOOP_CPR, cpr
| new_cpr);
- }
+ mdelay(5);
+ }
+
+ local_irq_save(flags);
+
Re: [Zaurus-devel] spitz kernel questions
Hi! I've got a C3000 I'm trying to juice every drop out of for my upcoming distro release so I've been wondering: .. * I've never done any cross compiling and especially without an overclocked Z I don't much fancy experimenting compiling my own kernel so who puts out the best pre-compilied spitz kernels and will it work with my zubuntu jaunty install? Could I use a kernel compiled under Lenny or sid, for example, without problems? If I must compile it myself it'd be good to be able to get a pre-configured kernel config file/ tree so I'd just have to do a 'make' and end up with a kernel I can be confident will work. I do my compiling natively; you can get my .config if you want to. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] zaurus spitz suspend/resume issue
Hi!
Since resuming my spitz from a suspended state doesn't work in
2.6.34-rc3
at the moment, I've tried to find out what the problem is with
suspend/resume. Using CONFIG_PM_DEBUG I tried to test this by setting
/sys/power/pm_test to core and switching the device off with the power
button. This indeed suspends and resumes the device, but shows following
in the system log:
It works here.
Or maybe we should allow these GPIOs to wakeup the system when either
configured as generic GPIOs or keypad GPIOs.
So... there's a bug in pxa-keypad driver -- it enables wakeup on one
line when it needs wakeup on all.
So we invented a workaround, in mfp-pxa2xx.c, where we change wakeup
on many lines when pxa-keypad wants to toggle wakeup on one.
But that workaround causes problems, so we
diff --git a/arch/arm/mach-pxa/mfp-pxa2xx.c b/arch/arm/mach-pxa/mfp-pxa2xx.c
index cf6b720..29301d2 100644
--- a/arch/arm/mach-pxa/mfp-pxa2xx.c
+++ b/arch/arm/mach-pxa/mfp-pxa2xx.c
@@ -178,8 +178,17 @@ int gpio_set_wake(unsigned int gpio, unsigned int on)
- if (d-keypad_gpio)
- return -EINVAL;
+ /* Allow keypad GPIOs to wakeup system when
+ * configured as generic GPIOs.
+ */
+ if (d-keypad_gpio (MFP_AF(d-config) == 0)
+ (d-config MFP_LPM_CAN_WAKEUP)) {
+ if (on)
+ PKWR |= d-mask;
+ else
+ PKWR = ~d-mask;
+ return 0;
+ }
Add more hacks on top.
What about simply fixing pxa-keypad? Then we can git of workaround,
and spitz will be fixed.
Fix should be as simple as replacing enable_irq_wakeup() with more
enable_irq_wakeup()s.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] zaurus spitz suspend/resume issue
Hi!
(please no html on lists)
On Sun 2010-04-18 21:00:13, - Cortez - wrote:
Since resuming my spitz from a suspended state doesn't work in 2.6.34-rc3
at the moment, I've tried to find out what the problem is with
suspend/resume. Using CONFIG_PM_DEBUG I tried to test this by setting
/sys/power/pm_test to core and switching the device off with the power
button. This indeed suspends and resumes the device, but shows following
in the system log:
Strange. Suspend works for me in 34-rc3. Config difference?
apm-power: Requesting system suspend...
PM: Syncing filesystems ...
done.
Freezing user space processes ... (elapsed 0.02 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PM: suspend of devices complete after 95.695 msecs
PM: late suspend of devices complete after 1.460 msecs
suspend debug: Waiting for 5 seconds.
PM: early resume of devices complete after 722.103 msecs
[ cut here ]
WARNING: at kernel/irq/manage.c:361 set_irq_wake+0xa4/0x130()
Unbalanced IRQ 191 wake disable
spitz has some crazy lets-link-irq-wakeups-together code, that
interacts badly with matrix kbd handler (but does not break
suspend). Try this.
Pavel
--- ./arch/arm.ofic/mach-pxa/mfp-pxa2xx.c 2009-09-10 00:13:59.0
+0200
+++ ./arch/arm/mach-pxa/mfp-pxa2xx.c2009-12-29 03:16:40.0 +0100
@@ -34,7 +34,6 @@
struct gpio_desc {
unsignedvalid : 1;
unsignedcan_wakeup : 1;
- unsignedkeypad_gpio : 1;
unsigneddir_inverted: 1;
unsigned intmask; /* bit mask in PWER or PKWR */
unsigned intmux_mask; /* bit mask of muxed gpio bits, 0 if no mux */
@@ -178,9 +177,6 @@
if (!d-valid)
return -EINVAL;
- if (d-keypad_gpio)
- return -EINVAL;
-
mux_taken = (PWER d-mux_mask) (~d-mask);
if (on mux_taken)
return -EBUSY;
@@ -231,32 +227,6 @@
#endif /* CONFIG_PXA25x */
#ifdef CONFIG_PXA27x
-static int pxa27x_pkwr_gpio[] = {
- 13, 16, 17, 34, 36, 37, 38, 39, 90, 91, 93, 94,
- 95, 96, 97, 98, 99, 100, 101, 102
-};
-
-int keypad_set_wake(unsigned int on)
-{
- unsigned int i, gpio, mask = 0;
-
- if (!on) {
- PKWR = 0;
- return 0;
- }
-
- for (i = 0; i ARRAY_SIZE(pxa27x_pkwr_gpio); i++) {
-
- gpio = pxa27x_pkwr_gpio[i];
-
- if (gpio_desc[gpio].config MFP_LPM_CAN_WAKEUP)
- mask |= gpio_desc[gpio].mask;
- }
-
- PKWR = mask;
- return 0;
-}
-
#define PWER_WEMUX2_GPIO38 (1 16)
#define PWER_WEMUX2_GPIO53 (2 16)
#define PWER_WEMUX2_GPIO40 (3 16)
@@ -273,6 +243,12 @@
gpio_desc[(gpio)].mux_mask = PWER_ ## mux ## _MASK; \
} while (0)
+
+static int pxa27x_pkwr_gpio[] = {
+ 13, 16, 17, 34, 36, 37, 38, 39, 90, 91, 93, 94,
+ 95, 96, 97, 98, 99, 100, 101, 102
+};
+
static void __init pxa27x_mfp_init(void)
{
int i, gpio;
@@ -291,7 +267,6 @@
for (i = 0; i ARRAY_SIZE(pxa27x_pkwr_gpio); i++) {
gpio = pxa27x_pkwr_gpio[i];
gpio_desc[gpio].can_wakeup = 1;
- gpio_desc[gpio].keypad_gpio = 1;
gpio_desc[gpio].mask = 1 i;
}
--- ./arch/arm.ofic/mach-pxa/pxa27x.c 2009-09-10 00:13:59.0 +0200
+++ ./arch/arm/mach-pxa/pxa27x.c2009-12-29 03:13:00.0 +0100
@@ -323,9 +323,6 @@
if (gpio = 0 gpio 128)
return gpio_set_wake(gpio, on);
- if (irq == IRQ_KEYPAD)
- return keypad_set_wake(on);
-
switch (irq) {
case IRQ_RTCAlrm:
mask = PWER_RTC;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] spitz 2.6.34-rc4: fix On/off key name to fix warning during boot
On/Off contains slash in the name, which causes warning during boot. Signed-off-by: Pavel Machek pa...@ucw.cz --- ./arch/arm/mach-pxa/spitz.c 2010-03-21 22:09:12.0 +0100 +++ ./arch/arm/mach-pxa/spitz.c 2010-04-16 03:45:07.0 +0200 @@ -363,7 +363,7 @@ .type = EV_PWR, .code = KEY_SUSPEND, .gpio = SPITZ_GPIO_ON_KEY, - .desc = On/Off, + .desc = On Off, .wakeup = 1, }, /* Two buttons detecting the lid state */ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] 2.6.34-rc3 vs zaurus spitz: mistery solved
Hi! For some reason, spitz will hang very early in boot with SLUB. With SLOB, it boots fine. SLUB worked fine in 2.6.33 and SLOB is hidden under CONFIG_EMBEDDED, so it took a while to figure out. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [regression] 2.6.34-rc1 to -rc3 on zaurus: no longer boots
I tried compiling 2.6.34-rc1, and it does not boot :-(. It does not seem to even reset the framebuffer (I'm using kexec -- so it stays stuck on on previous screen). Tried again with -rc2 and -rc3, and neither boots :-(. I did not have time to set up serial console, yet :-(. Any ideas? I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=15712 for your bug report, please add your address to the CC list in there, thanks! Pavel, you broke it ... and here you say something about sane arm maintainers ;-) ? You know which patch causes it ? Just have some time to try this out on my corgi, and the kernel runs happily. Pavel, Which exact model are you running your kernel? It is Zaurus SL-C3000 (aka spitz). I'm using kexec, but that used to work. Should I try minimal config? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] bit errors on spitz
On Sun 2010-03-21 22:42:33, Stanislav Brabec wrote: Pavel Machek píše v Ne 21. 03. 2010 v 21:43 +0100: On Fri 2010-03-12 10:07:04, Stanislav Brabec wrote: Good tip. It seems that nobody ported driver for the voltage control chip ISL6271 from 2.4 kernel, and bootloader probably does not set correct values. Are we sure about this one? If we have wrong voltages on various parts, that kind-off explains it. Would it be possible to measure (Voltmeter) difference between 2.4 kernel and 2.6 kernel? If you are ready to run Zaurus in dismantled state, then yes. Measure on the upper pin of the large coil in the center of the http://www.penguin.cz/~utx/zaurus/pcbt_uc.jpg image or on the testpoint nearby (probably to the right). I'm not comfortable dismantling it :-(. Alternatively, it is possible to write a driver. It is just one byte write and one byte read via I2C. Do you know what byte it is? That sounds easy enough... But I have small problem now -- zaurus seems to work mostly fine now. Does it depend on temperature, or what? Tried mtest, nothing. Tried compiling kernel, ok... Will try few more times... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] bit errors on spitz
On Mon 2010-03-08 12:48:36, Stanislav Brabec wrote: Cyril Hrubis wrote: Well I've seen empty lines when editing file with vim And I have seen: - Unreproducible SIGSEGV of gcc (while Wi-Fi connection over CF card was running). - Unreproducible SIGSEGV of opkg (downloading via Wi-Fi connection over CF card). - Unreproducible SIGSEGV of rm (called from find command launched via ssh, networking via Wi-Fi connection over CF card). (Hint: Tasks above are HDD-intensive.) - Lost blocks while copying from CF to SD. - Lost blocks while copying from HDD to SD. - Lost blocks while copying from CF to USB flash stick. - And I see display noise while CF Wi-Fi card is active. These problems appear in all kernels, at least since 2.6.26. There is no note in the syslog. Interesting, I get memory corruption leading to strange behaviour. Sometimes echo 3 /proc/sys/vm/drop_caches helps... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
Hi! I wasn't aware of this. That may be a good reason for adding kernel-based suspend notification, although I'd prefer ARM to notify the user space about the critical battery status allowing it to decide what to do. Hard to do, without breaking compatibility that goes down to 2.4.X. Sending a battery-critical notification to the user space is not equivalent to removing the existing kernel-based mechanism. They can exist both at the same time if the notification is sent earlier than the kernel suspends everything. Yes, and obviously sending notification early is ok with me. It really makes sense on zaurus. Those machines are simple, no smartbattery and no embedded controller subsystems. Battery will not protect itself, and its kernel job. (Should work on init=/bin/bash). As power-off consumption is same as suspend power consumption (I beleive zaurus simply does not have true power off), suspend on critical makes some sense. (Note that it is set lower than on pcs, and that we declare battery critical sooner than that.) The problem with that is it catches at least some applications unprepared and notifying them that we're suspending right now doesn't really help, because they won't have any time to react anyway. Agreed, but so what? On PC, machine would power off at that point. That would surprise the apps, too. Basically new enough userland should not make battery run low enough for either emergency power off or emergency suspend. IOW nothing to see here, problem does not exist. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [suspend/resume] Re: userspace notification from module
On Sat 2010-01-16 18:00:58, Stanislav Brabec wrote: Eric Miao wrote: And the other way we may need to look into what API the current userland apps on zaurus is depending on this 2.4 compatibility and make changes slowly to those apps. I guess that 2.4 compatibility is not an issue. Most modern Zaurus distributions are even unable to run Sharp ROM compatible binaries. Distributions either stay on 2.4 kernel or use modern systems based on modern kernel 2.6 API. Distributions that decided to migrate to kernel 2.6 are far from finished state. Any change that allows to use modern applications using standard kernel API is welcome. There is no API involved. It is just ... if you leave zaurus in init=/bin/bash mode, it must not kill the battery. Smart and currently implemented way to do that is to suspend. That's counterexample to rjw, but it does not matter -- reasonable userland should never ever hit that, in a same way PCs should not hit emergency power cut... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] corgi_ts
Hi! I wrote a part of resistive_keypad driver[1], but did not finish it. Interesting :-). Is it still possible to buy this kind of remote control somewhere / does anyone have any extra / ... I guess it should be quite easy to make one...? Ok, I guess I should fix audio, first... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
