Re: [Zaurus-devel] kernel panic in spi_complete() on spitz (PXA270)
Pavel Herrmann wrote: On Thursday, June 30, 2011 04:45:18 PM Stanislav Brabec wrote: Then I tried to apply [PATCH] MAX: Fix race condition causing NULL So I guess that MAX AC voltage reading (via SPI) was involved in an incorrect moment and race happened there and your MAX race condition fix fixes it. Are you using the first or second version of the patch? if the former, please use v2 (sent a few days later), which has solved the same problem by using a mutex instead of allocating message data on stack (which is not good for DMA) I guess the second one with mutex. This is my work-in-progress-mix patch: http://www.penguin.cz/~utx/zaurus/feed/images/spitz/zImage-3.0.0-rc5+-spitz.diff Several hours later, charging was turned on/off at least 1000 times without any crash. So it seems that it was the correct race condition fix. as for the backstory, this crash ocurrs when a short (measured in time spent) message was enqueued after a long message, so that the short one finished first (the actual bug was present even if the long one finished first, but in that case there was double complete() on the one completion instead of a NULL dereference) I guess that inserting of power supply initiates reading of voltages on MAX. The long one may be touchscreen or LCD control. -- Stanislav Brabec http://www.penguin.cz/~utx ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] kernel panic in spi_complete() on spitz (PXA270)
0013 [c0024b84] (__irq_svc+0x44/0xcc) from [c002edd8] (xscale_flush_user_cache_range+0x18/0x3c) [c002edd8] (xscale_flush_user_cache_range+0x18/0x3c) from [c00affd8] (try_to_unmap_file+0x98/0x4ec) [c00affd8] (try_to_unmap_file+0x98/0x4ec) from [c00b07ac] (try_to_unmap+0x40/0x60) [c00b07ac] (try_to_unmap+0x40/0x60) from [c009b940] (shrink_page_list+0x2a8/0x8cc) [c009b940] (shrink_page_list+0x2a8/0x8cc) from [c009c448] (shrink_inactive_list+0x218/0x344) [c009c448] (shrink_inactive_list+0x218/0x344) from [c009c8f8] (shrink_zone+0x384/0x4ac) [c009c8f8] (shrink_zone+0x384/0x4ac) from [c009ceb0] (kswapd+0x490/0x7d0) [c009ceb0] (kswapd+0x490/0x7d0) from [c0059be0] (kthread+0x90/0x98) [c0059be0] (kthread+0x90/0x98) from [c00258d8] (kernel_thread_exit+0x0/0x8) Code: e3843080 e121f003 e3a1 ebfff96a (e5953000) ---[ end trace a4b97c165577d355 ]--- Kernel panic - not syncing: Fatal exception in interrupt [c00298fc] (unwind_backtrace+0x0/0xe4) from [c0295e1c] (dump_stack+0x18/0x1c) [c0295e1c] (dump_stack+0x18/0x1c) from [c0295e84] (panic+0x64/0x18c) [c0295e84] (panic+0x64/0x18c) from [c002842c] (die+0x300/0x358) [c002842c] (die+0x300/0x358) from [c002c294] (__do_kernel_fault+0x6c/0x90) [c002c294] (__do_kernel_fault+0x6c/0x90) from [c002c508] (do_page_fault+0x250/0x270) [c002c508] (do_page_fault+0x250/0x270) from [c0024214] (do_DataAbort+0x38/0xa0) [c0024214] (do_DataAbort+0x38/0xa0) from [c0024b2c] (__dabt_svc+0x4c/0x60) Exception stack(0xc3897b20 to 0xc3897b68) 7b20: 0004 0103 c3896000 a013 c30f0da8 7b40: 000a c381f3e0 c4806000 c3897b84 c3897b68 c3897b68 c0036b6c c0036b6c 7b60: 8093 [c0024b2c] (__dabt_svc+0x4c/0x60) from [c0036b6c] (complete+0x28/0x7c) [c0036b6c] (complete+0x28/0x7c) from [c01e9b0c] (spi_complete+0x10/0x14) [c01e9b0c] (spi_complete+0x10/0x14) from [c01eac2c] (giveback+0x114/0x12c) [c01eac2c] (giveback+0x114/0x12c) from [c01eb60c] (pump_transfers+0x13c/0x6f8) [c01eb60c] (pump_transfers+0x13c/0x6f8) from [c0044924] (tasklet_action+0x90/0xf0) [c0044924] (tasklet_action+0x90/0xf0) from [c0044eb8] (__do_softirq+0x98/0x138) [c0044eb8] (__do_softirq+0x98/0x138) from [c00453a0] (irq_exit+0x4c/0xa8) [c00453a0] (irq_exit+0x4c/0xa8) from [c002406c] (asm_do_IRQ+0x6c/0x8c) [c002406c] (asm_do_IRQ+0x6c/0x8c) from [c0024b84] (__irq_svc+0x44/0xcc) Exception stack(0xc3897c78 to 0xc3897cc0) 7c60: 4022d320 4022e000 7c80: 0875 1000 c32273c0 c03ce1c0 c2b49b78 4022d000 c2b420b4 0001 7ca0: c3897cfc c3897cc0 c00afc54 c002edd8 0013 [c0024b84] (__irq_svc+0x44/0xcc) from [c002edd8] (xscale_flush_user_cache_range+0x18/0x3c) [c002edd8] (xscale_flush_user_cache_range+0x18/0x3c) from [c00affd8] (try_to_unmap_file+0x98/0x4ec) [c00affd8] (try_to_unmap_file+0x98/0x4ec) from [c00b07ac] (try_to_unmap+0x40/0x60) [c00b07ac] (try_to_unmap+0x40/0x60) from [c009b940] (shrink_page_list+0x2a8/0x8cc) [c009b940] (shrink_page_list+0x2a8/0x8cc) from [c009c448] (shrink_inactive_list+0x218/0x344) [c009c448] (shrink_inactive_list+0x218/0x344) from [c009c8f8] (shrink_zone+0x384/0x4ac) [c009c8f8] (shrink_zone+0x384/0x4ac) from [c009ceb0] (kswapd+0x490/0x7d0) [c009ceb0] (kswapd+0x490/0x7d0) from [c0059be0] (kthread+0x90/0x98) [c0059be0] (kthread+0x90/0x98) from [c00258d8] (kernel_thread_exit+0x0/0x8) My config: http://www.penguin.cz/~utx/zaurus/feed/images/spitz/config-3.0.0-rc4+-spitz Only small ads7846 patch was applied on top of it: http://www.penguin.cz/~utx/zaurus/feed/images/spitz/zImage-3.0.0-rc4+-spitz.diff -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] touchscreen calibration issues (again)
Andrea Adami wrote: Hello, here we are again: touchscreen does not calibrate (and pointercal values are not totally correct). Yestarday built Angstrom images did not ship ts_* utils anymore and the two tools provided both fail: (on SL-C860) xinput_calibrator Error: no calibratable devices found. xtscal xcb_io.c:515: _XReply: Assertion '!dpi-xcb-reply_data' failed Aborted You have two ways to calibrate: Xfbdev + tslib + xtscal: works well Xorg + xf86-input-tslib + ?: Broken, X crashes on start. Needs porting. Xorg + xinput_calibrator: Works, but due to too much noise in the ads7846 kernel driver, it is totally unusable. Pointer skip 50-100 pixels early after tap, calibration is totally out. Somebody should take patches from Vitaly Minko and port them to the latest kernel. Patches were sent in first days of this list (09 Nov 2009), but they were based on kernel 2.6.24. If I understand, the issue has been resumed here: http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/002502.html Well, kdrive should probably go to the handhelds feed or so. Xorg still needs some work to become a replacement of kdrive: - implement software driven Xrandr in the fbdev driver - optimize operations in software rotated fbdev driver - save some memory in core drivers Origin: [PATCH] Remove xcalibrate and tslib support http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/10614 Well, we can create patched libXext version that will be installed by kdrive people. I think it's time to concentrate on a *single* solution and debug it. Maybe xserver-xorg today? kdrive: Probably easy to do. 1. Revert all removals of tslib support and create special packages with a special name (as it were done for xserver-kdrive-1300). 2. Fix OE xserver-common to not mix Xorg and kdrive command line args (comment out detection of Xorg is a work-around). Xorg: 1. Fix ads7846 kernel driver noise (better solution) or fix xf86-input-tslib (worse solution) 2. Fix OE xserver-common to not mix Xorg and kdrive command line args (remove command line arguments except dpi is a work-around). 3. Fine tune xorg.conf. Make memory footprint of Xorg as small as possible. I have a working xorg.conf for spitz and a nice XKB keyboard map for zaurus which can be used as a start point: http://ftp.penguin.cz/pub/users/utx/zaurus/files/xserver-xorg/ -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ 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
Pavel Machek wrote: Umm, can you raise the issue on linux-input? New kernel should not break old tslib... They probably know, why they increased EV_VERSION. If we are sure that that change does not break tslib, we should patch tslib to accept both versions. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ 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
Andrea Adami wrote: ... even tslib started to work again for unknown reason, Xfbdev works, Xorg works (but it is unusable due to very noisy ADS7846 driver and broken xf86-driver-input-tslib). I can confirm that touchscreen 'works' again on corgi(C860) and poodle. Well, I cannot. My OE image is broken again. That is why I copied my old good 2.6.26RP image to the new OE image (plus odev-compat stuff), and I was surprised - touchscreen does not work there as well. So it is definitely issue outside kernel. Just some issues to cure: - poodle(kdrive-fbdev): at gpe login touchscreen calibration is requested, crosshairs are plotted, after calibration no input from keyboard/virtual kerboard :/ - c7x0(kdrive-imageon): pointercal defaults are used (and those are slightly wroing on my 2 corgi C860). Gpe login is ok, keyboard working. Though, if you try to recalibrate from within gpe the crosshairs are not drawed so calibration is impossible Yes, I seen this bug in Xfbdev pointercal as well on SL-C3200. But Xorg calibration now works (well, the application works, but short tap paints a pretty long line, so the result of calibration is still unusable). I am now trying to locate the regression (or race condition?). Is the current OE still using module autoload? Or was this moved to udev and platform device tables? I the latter case the fix should be done in the kernel. Ah, this is nice question: we newly came on open air after years with 2.6.2x and now we'll discover new bugs;) FWIW in OE there is a mix of modules management: some are in kernel.bbclass, others in linux.inc and finally in machine.conf. I'm still trying to understand what's happening using latest udev. Well, again - snd-soc-spitz-not-autoloaded is a regression outside kernel. The old kernel with the new OE image has the same problem. (It means, that the kernel never provided correct info for udev module autoloading.) -- Stanislav Brabec http://www.penguin.cz/~utx ___ 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
Pavel Machek wrote: 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...). Search for SPITZ_SCP_CF_POWER. It controls power to both SD slot and external CF slot. And it seems to be missing in SPITZ_SCP*_SUS_*. (It was always missing, but it was controlled by spitz_card_pwr_ctrl() which disappeared from the recent kernels.) -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ 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
Andrea Adami wrote: 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, Bluetooth works, even tslib started to work again for unknown reason, Xfbdev works, Xorg works (but it is unusable due to very noisy ADS7846 driver and broken xf86-driver-input-tslib). Regarding the defconfig and spitz embedded hardware, the driver for ICL7106A and PXA RTC were missing or not loaded. I don't know about sound (I found the fix sent to the list with my kernel). I have maintained my experimental configs separately since 2.6.26-RP. It diverged a lot. I am not sure about effect of many generic kernel settings. Which one is better and which one is worse... I'll compare your one and my one. For example, yesterday I have found an option, that considers SD card removal/insertion during suspend (MMC_UNSAFE_RESUME). It would be nice to have this option disabled. But it makes impossible to suspend when booting from SD. (Work-around: While booting from SD, bootloader have to pass proper removable value to the kernel MMC driver (I did not test it yet). please post/commit the shrinked defconfig (make savedefconfig): I'm trying to keep all the Zaurus in sync and that's much easier to diff. Thanks for the hint. FWIW USB-host is only for spitz/akita/tosa, though. Yes, it is. But USB host is very important for many users (like me). Your config lacks many useful external USB devices support: - USB HCI - required for any generic USB Bluetooth dongle. - More WLAN drivers (my WLAN dongle is RT3070 and it is one of few dongles, that is able to live with 150mA. People using external power or power hack may need other WLAN USB drivers). - USB to serial adapters are needed not only for serial cables, but also for many other devices (GPS, Arduino,...). - I don't have any Ethernet adapters, but people have. - Guessing whether somebody needs more obscure drivers like special USB keyboards, SDIO GPS. Regarding the missing sound: This is just an easy bug in the kernel platform tables - udev does not know that it should load snd-soc-spitz. Loading it manually works-around the problem. Pls check machine/include/zaurus.inc Are you sure we have the right modules configuration (btw it's a mess in OE)? I just copied the lines from linux-rp.inc... Yes, it seems that we have right modules. Just snd-soc-spitz is not autoloaded after the boot (it happened with 2.6.26-RP). I see loaded snd-soc-pxa2xx-i2s (required for the I2S bus) and snd-soc-wm8750 (codec driver), but not snd-soc-spitz (it defines Spitz sound routing and controls additional mute transistors). Is the current OE still using module autoload? Or was this moved to udev and platform device tables? I the latter case the fix should be done in the kernel. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ 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
Andrea Adami wrote: On Fri, May 6, 2011 at 4:37 PM, Stanislav Brabec u...@penguin.cz wrote: Hallo. 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). - I was not able to return from suspend (boot from SD, no reaction on On/Off press). I even suspect that my Zaurus seems to be warmer that it should be. Maybe CPU is not sleeping? This seems to work (angstrom-console-image) http://paste.debian.net/116495/ Yes, it works, but not every time. - Xfbdev lack touchscreen support (libts does not understand the latest input device). I did not test Xorg yet. - tskeys are running at 100% CPU time (known bad design). Surely there are issues with tskeys/touchscreensee logs Good thing happened and now it works again in the OE image built yesterday from scratch. (Both tskeys and Xfbdev+tslib touchscreen.) And yet another good news: Xorg requires much less memory than a year ago. Fine tuning enabled modules may probably improve the number even a bit more. I already have a nice XKB keymap with two keymap switching hotkey, CapsLock support. I want to finish F-key support. spitz - http://paste.debian.net/116489 I see no sound as well - probably misconfiguration. - 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. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] latest angstrom image + linux-2.6.38.4 report
Hallo. 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. - I was not able to return from suspend (boot from SD, no reaction on On/Off press). I even suspect that my Zaurus seems to be warmer that it should be. Maybe CPU is not sleeping? - Xfbdev lack touchscreen support (libts does not understand the latest input device). I did not test Xorg yet. - tskeys are running at 100% CPU time (known bad design). - HDD LED seems to not work. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ 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.
MyungJoo Ham wrote: As long as sysdevs are resumed and some devices/subsystems (I2C-PMIC, ADC, and RTC in my cases) can be selectively resumed and suspended, it is fine. Thus, your alternative suggestion is perfect with me. Actually, this is almost going back to the original hack. =) I'll submit next revision with platform_suspend_ops later. Does kernel have something like sleepy task interface, e. g. special mode that is triggered by some sort of interrupt and instead of going to perform full resume, it just lets a hook to wake up manually needed devices, perform the sleepy task and then tell the system whether full resume is requested? It can fit for Zaurus battery charging monitoring - timer interrupt needs to wake just the SPI bus. But I can imagine a GPS logger using such interface to save energy - serial interrupt semi-wakes the system each second, but will not go to do full resume. It just processes NMEA sentence and buffers the result. Only if buffer becomes full, it issues full resume and writes data somewhere. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
[Zaurus-devel] rule out 170mA USB device claim
Maybe you have a device that rejects to work, because it claims to need
500mA or so. But in fact it works, just it claims to need much more
energy than it really needs.
Here is a small hack to work-around this problem and force the device to
start without any interaction:
/lib/udev/rules.d/40-ralink.rules:
# Ignore power requirement for Ralink 3070. It can run with 170mA.
SUBSYSTEM==usb, ACTION==add, ATTRS{idVendor}==07b8,
ATTRS{idProduct}==3071, RUN+=/bin/sh -c 'echo 1 /sys%p/bConfigurationValue'
If you have more similar USB IDs, then it may make sense to make a list
and create an Angstrom package for that.
(Note that the current Ralink 3070 driver requires 4x 256kB of
contiguous kernel memory to start. It is really awkward, and I have
often to call echo 3 /proc/sys/vm/drop_caches and/or
dd if=/dev/zero of=/dev/null bs=62M count=1 to wipe or swap out some
data.)
--
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus
___
Zaurus-devel mailing list
Zaurus-devel@lists.linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Zaurus: kernel 2.6.38
Andrea Adami wrote: it seems vanilla kernel 2.6.38 boots just fine on all Zaurus models. We have fresh recipes in OpenEmbedded (linux and linux-kexecboot) for c7x0, akita, spitz, poodle. Collie and tosa will be committed later today. Not only that it boots. Even battery seems to survive overnight suspend! I just seen following problems: - I guess that I seen some errors about missing audio (untested). - tslib stopped to understand /dev/input/touchscreen0. After fixing these two issues, it may be a good candidate for update the default kernel in the feeds. And long time running issues: - Serial without console may need to close/open after suspend to work again. - Suspend still has problems with MAX (but offline charging surprisingly seems to work, I did not test whether even stopping of charging works) - Unfiltered touchscreen precision is still tragical (50 pixel jumps are not exceptions). - I still did not find to finish my resistor array keyboard driver (AKA remote control). I will probably port the old one to get remote working there. - Status of filesystem corruptions is not known (it is happening with varying frequency in all 2.6 kernels). -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [Off-Topic] C760 screen
Simon Siebert wrote: Hi, i know, this is off-topic, but there are nearly no discussion boards etc. about the Sharp Zaurus. I have got a SL-C760 with a broken screen. The touch works on the complete area, but it doesn't display correctly. The LCD is broken. Does anybody have an idea were to get a new screen. Or a compatible one? Original part number for C3000 is Sharp WLLS037V1P01 (I hope I read it correctly from the photo, plese fix me if you order the original). Sharp LS037V7DW01 may be pin compatible, but it does not have off-screen buttons. New product ID for that display is LS037V7DW03 (probably still in production), but that one may need resistor change on the PCB. It even has a transreflective version. Here you can find what I found: http://www.penguin.cz/~utx/zaurus/datasheets/LCD/ No guarantee! I did not had any of these displays in my hands. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Zaurus: kernel 2.6.38
Andrea Adami wrote: Third step is the new event-driven zaurusd. Cyril Hrubis wrote something. http://metan.lindevdoc.org/git/?p=zaurusd.git/.git;a=summary I also started to write a small dbus service (service watching input device and sending rotation and audio switch events to clients - probably rotation, audio and brightness applets on the screen), but never finished. Fourth step (to be discussed) is moving all to xorg-xserver. It's basically possible and I already succeeded. I even wrote a nice keymap with working CapsLock (programming XKB is crazy!) and layout switch. http://ftp.penguin.cz/pub/users/utx/zaurus/files/xserver-xorg/ But last time I tried it (a year ago), it needed extra ~15 megabytes of RAM. It's not acceptable for device with 64MB of RAM. Another blocker is the fuzz of the touchscreen device (if we don't want to use depecated tslib input device). There exists some patches from Vitaly Minko sent to this list. (Note that thread started early after setup of this list and it is not archived completely.) http://lists.linuxtogo.org/pipermail/zaurus-devel/2009-November/13.html Again, Cyril Hrubis wrote a generic event filter, which can perform similar job. http://atrey.karlin.mff.cuni.cz/~metan/evfilter/ -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Zaurus: kernel 2.6.38
Yury Bushmelev wrote: I also started to write a small dbus service (service watching input device and sending rotation and audio switch events to clients - probably rotation, audio and brightness applets on the screen), but never finished. I'm interested in such thing for my ThinkPad X61 tablet :) Have you published your work anywhere? Doing just now. It is a WIP, but it may help a bit. Commented code is stolen from another projects and needs to be adjusted. http://ftp.penguin.cz/pub/users/utx/zaurus/evdevd-unfinished.tar.bz2 The top directory contains some learning examples. The code intended to be release is in evdevd-0.1. I wanted to write it without glib or any other dbus proxy. It makes code a bit more complex and especially I had to learn use of select(). The idea is following: When client starts, it queries for the current status by .../Evdevd/GetLid. It will starts listening on .../Evdevd/Lid would to get change signals. I was not yet decided whether force rotation or force headphone mode should be part of the daemon or part of the client. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ 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
Franck L wrote: 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. Feel free to try my ones: http://www.penguin.cz/~utx/zaurus/feed/images/spitz/ (config*) -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] cf speed evolution
kirill wrote: Hi! Recently I've upgraded internal cf on my c3000. So now I have a better idea of what cf storage performance you can get with c3000 hardwire. Benchmark results (2.6.19 kernel, dd if=/dev/hda of=/dev/null): 1) unmodified kernel: ~ 2MB/sec 2) optimized timings, 250ns io cycle: ~ 3MB/sec Well, I tried your patch from the list on 2.6.26-RP. I see 2.33 MB/sec - 2.63MB/sec improvement on 6 years old 40x card. 3) optimized timings, DMA patch, 250ns io cycle: ~ 4MB/sec 4) optimized timings, DMA patch, 120ns io cycle: ~ 5.5MB/sec 5) optimized timings, DMA patch, 120ns io cycle, different cf card: ~ 6.3MB/sec 120ns io cycle = CFA advanced I/O timing mode supported by the card. DMA patch = ide-cs patch, which adds support for memory-to-memory style DMA to transfer data from IDE data register to memory buffer. Do you have a patch for these things? Well, I guess that also SD runs slower than it could. PXA270 datasheet[1] says, that it can run 9.75MB/sec on SD. I see 1.8MB/s. [1] http://www.penguin.cz/~utx/zaurus/datasheets/CPU/Intel%20PXA27x%20Processor%20Family%20Developer's%20Manual.pdf page 15-1 -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.34 power management status
Stanislav Brabec wrote: 1. Fast charging during suspend does not work (see log at the end of this mail). One have either reboot to bootloader to get battery charged or wait about 16 hours and charge while Zaurus is up. Well, it seems to be a bit worse. My Zaurus totally discharges overnight. I have to remove battery for awhile to reset battery fatal undervoltage protection. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.34 power management status
Andrea Adami wrote: what is the situation about power management/ battery drivers? 2.6.34 seems mature for production use on spitz / corgi (well, usb still to test) apart proper power management. Any update? I just testes yesterday's vanilla: Actually I see these regressions in comparison with 2.6.26-RP: 1. Fast charging during suspend does not work (see log at the end of this mail). One have either reboot to bootloader to get battery charged or wait about 16 hours and charge while Zaurus is up. To fix this situation, we have to: 1.1 Rewrite max_read_channel() cross linking with sharpsl_pm. it is completely bad approach - kernel is not aware that sharpsl_pm is cross linked with drivers/hwmon/max.c. It is already suspended when sharpsl_pm attempts to read battery status. Threads pointing to the correct implementation: http://archives.free.net.ph/message/20100126.214515.1170de0a.ca.html http://www.mail-archive.com/zaurus-devel@lists.linuxtogo.org/msg00154.html 1.2 Invent a way, how to charge battery during sleep. Either call bootloader somehow (if possible), or wake up SPI (or not suspend it), read value, suspend SPI, perform battery control and continue in sleeping. 2. Possible minor problems in USB initialization. See thread usb gadget on zaurus and kexec in linux-arm-kernel last week. I just tested USB host with yesterday's vanilla. I failed once, second time succeeded. (Maybe it depends on the state of the master kernel when kexec is called). It needs further debugging. 3. There is new regression in no_console_suspend. I sent a very tricky patch for unbreaking serial after resume with no_console_suspend in past. Now it is broken again in different way: serial is alive after resume, but serial setting is not correct. Very minor regression, we can live with it. Here is a log with no_console_suspend that cleanly shows broken charging: 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. hostap_cs: CS_EVENT_PM_SUSPEND PM: suspend of devices complete after 309.430 msecs PM: late suspend of devices complete after 2.941 msecs max spi2.2: spi_sync failed with -108 max spi2.2: spi_sync failed with -108 max spi2.2: spi_sync failed with -108 max spi2.2: spi_sync failed with -108 max spi2.2: spi_sync failed with -108 sharpsl-pm sharpsl-pm: Error: AC check failed: voltage -108. sharpsl-pm sharpsl-pm: Offline Charger: Error occurred. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ 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
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). Alternatively, it is possible to write a driver. It is just one byte write and one byte read via I2C. Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Suspend issues
On Mon, 2010-02-08 at 19:16 +0300, Vitaly Minko wrote: I've installed 2.6.33-rc6 on my Akita. Works fine in general. Here are few annoying issues I found: 1. When I hold on/off button for 1-2 seconds while resuming, Zaurus blinks for a moment and dies. Only suspends, next short press will resume for me. I guess it is related with the level triggered resume, where driver expects edge triggered resume. See the thread sharp c-3000 aka spitz: fix warn_on introduced in 2.6.32-rc1 / gpio_keys and how PXA27x sets gpio_set_wake() If this is not the source of problems, then there are key debouncing problems. -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Original 2.4 files and sources
Andrea Adami wrote: links on this page are pointing to the (disappeared) 2.4 sources: http://tetsu.homelinux.org/zaurus/kernel/ There are the original updaters too. And here is my (partial) mirror: http://www.penguin.cz/~utx/zaurus/support.ezaurus.com/ Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] gpio_keys and how PXA27x sets gpio_set_wake() (was Re: sharp c-3000 aka spitz: fix warn_on introduced in 2.6.32-rc1)
Eric Miao wrota: I prefer 2) - the ugly and hardcoded setup in spitz_pm.c should really be removed. That's why the gpio_set_wake() and keypad_set_wake() are introduced. I am unsure, whether gpio_keys driver is interested in the way, how wake happens. I guess that is interested only in the fact, that wake happened. Handling platform specific edge/level wake setup would only complicate the code. (In fact, even the PXA270 platform code does not exist yet - arch/arm/mach-pxa/mfp-pxa2xx.c:__mfp_config_gpio() is not capable to configure Power Manager Keyboard Wake-Up Enable Register (PKWR).) I talked to Vojtěch Pavlík and he told that 1 is correct: Follow include/linux/interrupt.h. Setting edge/level wake mode should be done in the platform file. The driver could use just irq_set_wake() and don't care about details. And irq_set_wake() should do something useful even for PKWR capable GPIO. keypad_set_wake() is really specifically introduced for use by pxa27x_keypad and no generic GPIO stuffs. So it's really annoying a GPIO will use the PKWR as a wakeup GPIO, I'd recommend one still get this hard coded into the platform file, with combination of WAKEUP_ON_LEVEL_HIGH (which is specifically designed for keypad GPIOs) and keypad_set_wake(). Well, keypad_set_wake() seems to be possibly broken for GPIO 38. Imagine a device, that has a small keypad, but GPIO 38 has a different purpose that requires an edge triggered wakeup (PWER). I think that keypad_set_wake() reprograms it to PKWR. The problem affects gpio_keys: It is a driver implementing one key per gpio. It now handles On/Off and lid switches on Zaurus. Lid switches are on normal GPIOs, On/Off switch is wired to PKWR capable GPIO. The spitz, however, is doing a good job on this though it's using a GPIO emulated matrix keypad, that there is a separate SPITZ_GPIO_KEY_INT, which triggers whenever there is any key press on this matrix (I don't know how that's designed in HW, but it seems to do that job), and which can be setup as a GPIO wakeup. SPITZ_GPIO_KEY_INT happens if AC adapter is connected or key is pressed. Surprisingly, the key press logic is part of NAND flash controller CPLD. SPITZ_GPIO_KEY_INT==0 - it makes possible to wake Zaurus even from deep sleep by any key press. It would be impossible only with PKWR. I guess that this and implementation of keypad_set_wake() is a reason, why most devices suspend and resume correctly even if the irq_set_wake() refuses to configure wake and the warning is only visible symptom. Stanislav Brabec http://www.penguin.cz/~utx ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] gpio_keys and how PXA27x sets gpio_set_wake() (was Re: sharp c-3000 aka spitz: fix warn_on introduced in 2.6.32-rc1)
Eric Miao wrote: 2010/1/26 Stanislav Brabec u...@penguin.cz: Eric Miao wrote: 2010/1/26 Stanislav Brabec u...@penguin.cz: Handling platform specific edge/level wake setup would only complicate the code. (In fact, even the PXA270 platform code does not exist yet - arch/arm/mach-pxa/mfp-pxa2xx.c:__mfp_config_gpio() is not capable to configure Power Manager Keyboard Wake-Up Enable Register (PKWR).) That's why WAKEUP_ON_EDGE_* is introduced, no need for gpio-keys to know this. But WAKEUP_ON_EDGE_* is impossible for GPIO 95, enable_irq_wake()/gpio_set_wake() returns EINVAL and disable_irq_wake() complains on Unbalanced IRQ 191. Now I see, but I don't know why disable_irq_wake() will complains about unbalance since it should really manage it well. Because gpio_set_wake() returned EINVAL, set_irq_wake() assumed error and did not increment wake_depth, the whole enable_irq_wake() was a big NOP. disable_irq_wake() seen wake_depth being zero and complains. A quick dirty solution would be the platform to call keypad_set_wake() directly somewhere. Otherwise we have to let gpio_set_wake() to handle those keypad GPIOs and to live together with keypad_set_wake() happily, which is really difficult. I was thinking about it as well (and even tested that it works): gpio_set_wake(): if (d-keypad_gpio) return keypad_set_wake(on); But keypad_set_wake() always sets all keypad GPIOs, not just a single one. And there is GPIO 36, that can be configured in more ways. gpio_set_wake() and only set wake, keeping the mode as it was before. (Well, it's again impossible for GPIO 36 without storing this information somewhere.) But well, another idea: Only matrix_keypad driver should be aware of level triggered wakeup. All other drivers could follow *_irq_wake documentation and not care about it. If edge triggered interrupt is available, it should be preferred there, if not, level triggered wake should be used instead. Hardware designers should know what they are doing. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] sharp c-3000 aka spitz: fix warn_on introduced in 2.6.32-rc1
Eric Miao wrote: I don't get it; what is pxa27x_keypad used on? It looks like matrix-keypad subset. pxa27x has its own specific keypad controller. And since we now use enable_irq_wake, and the keypad controller has only one such IRQ_KEYPAD, will have to setup the keypad GPIO wakeup as a whole. Looking deeper into it, the problem seems to be elsewhere: I just added debug message to start and end of set_irq_wake(). And here is what I got during suspend: set_irq_wake() started IRQ: 191 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 191 to 1, desc-wake_depth: 0 set_irq_wake() started IRQ: 108 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 108 to 1, desc-wake_depth: 1 set_irq_wake() started IRQ: 113 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 113 to 1, desc-wake_depth: 0 set_irq_wake() started IRQ: 187 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 187 to 1, desc-wake_depth: 0 set_irq_wake() started IRQ: 130 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 130 to 1, desc-wake_depth: 0 set_irq_wake() started IRQ: 132 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 132 to 1, desc-wake_depth: 0 set_irq_wake() started IRQ: 134 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 134 to 1, desc-wake_depth: 0 set_irq_wake() started IRQ: 135 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 135 to 1, desc-wake_depth: 0 set_irq_wake() started IRQ: 31 to 1, desc-wake_depth: 0 set_irq_wake() done IRQ: 31 to 1, desc-wake_depth: 1 I think that if (desc-wake_depth == 0) when set_irq_wake(foo, 1) is done, then something went wrong. And it is not surprise, that it reports Unbalanced IRQ on resume. Note that other people (Cyril Hrubiš) with a bit different .config report success with gpio keys driver turned on. My config: http://www.penguin.cz/~utx/zaurus/feed/images/spitz/config-2.6.33-rc4-spitz OT: Serial console resume did not work properly even with no_console_suspend and my patch: [PATCH 4/8] serial-core: resume serial hardware with no_console_suspend Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] Zaurus-devel Digest, Vol 3, Issue 18
flameman mayer wrote: so ... i am really thinking about un soldering my akita SIR chip, replacing it with a simple manchester enc/dec directly connected to Ir led/ Ir photo transistor =P IrDA uses baseband modulation with no carrier (1=silence, 0=pulse): http://www.irda.org/associations/2494/files/Publications/Physical%20Basics.pdf You need Manchester (0=0then1, 1=1then0): http://en.wikipedia.org/wiki/Manchester_code Zaurus uses hardware SIR decoder similar to this one: http://www.penguin.cz/~utx/zaurus/datasheets/IrDA/gp2w0150xp_e.pdf I am afraid that it is incompatible on physical layer. You can unsolder it or maybe connect it in parallel, or use different ttyS. -- Stanislav Brabec http://www.penguin.cz/~utx ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] 2.6.33-rc1: good news
Andrea Adami wrote: Hello Stanislav, Unfortunately I have a fresh report from JaMa about wrong... BTW this was on Spitz. So the question is: does the prom appear somewhere in /proc/partitions? I could not find it on say mtd3... It should (I don't have the latest vanilla just now). And using /proc/mtd it could be identified. Kernel makes no guarantee of partition order. It depends on order of evaluation. If both drivers (PROM, NAND) are in modules, it can vary even across reboots. Ok, so what to do? Patch the kernel? It is more generic problem. It seems that kernel does not guarantee order of devices. The order changed even for CF slots: In 2.6.26 internal slot was listed first. Now external slot is listed first. The same problem affects keyboard (kernel with CE-RH2 remote support enumerates touchscreen differently. How do other boards with NOR and NAND do? Modern devices use OneNAND or similar and don't need any PROM. With a single MTD, numbers are stable. But this is critical problem only for boot. In the user space, there is a lot of chances to prevent it (udev, mount by ID). Imho we should respect the factory layout and keep kernel in mtd1. Note: I sent a patch to the kernel that fixes PROM layout and introduces two partitions in PROM: Boot PROM System and EN-JP DB3. So it would not be possible. Either mtd0 or mtd2. SharpROM$ cat /proc/mtd dev:size erasesize name mtd0: 006b 0002 Filesystem mtd1: 0070 0002 smf mtd2: 02b0 0002 root mtd3: 04e0 0002 home -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] corgi_ts
Yuri Bushmelev wrote: 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...? You can make it yourself. Here is manual in german: http://www.relei.de/zaurusfernb.html There is an incorrect value in the table. To Rene Kommzu: Could you fix marked values, please? Correct resistor values for CE-RH2 (serial connection of resistors): R1 330 Ohm Stop R2 470 Ohm Play/Pause R3 680 Ohm Next Song R4 910 Ohm Volume Up R5 1.5 kOhm Previous Song R6 3.3 kOhm Mute R7 10 kOhm Volume Down-- Resistances (for serial connection): And in table Testwerte zwischen Pin GND und Key please also correct: T7 17190 Ohm -- -- Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] corgi_ts
Pavel Machek wrote: Interesting :-). Is it still possible to buy this kind of remote control somewhere / does anyone have any extra / ... Maybe some e-shops still have it. But it costs $100 together with headphones[1]. I guess it should be quite easy to make one...? Yes, it is. Some people even modified $10 remote for another device to fit Zaurus. The connector is a standard R-ring 3.5mm barrel connector[2]. But be aware, cheap 3.5mm barrel connectors that don't exactly conform to the standard size don't fit inside. But I think that the generic driver should easily handle any similar remote. It can be used also as input for one analog potentiometer, as two range resistance meter (well, in high-resistance mode you would need polling), voltmeter 0-to-ref or as a 1-bit output or input GPIO. Ok, I guess I should fix audio, first... It does not work? Last time I tried vanilla kernel, it worked without any problems. At least for high bit rates. [1] http://www.penguin.cz/~utx/zaurus/photos#ce-rh2 [2] http://www.penguin.cz/~utx/zaurus/hardware#audio Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
Re: [Zaurus-devel] [patch] fix strange characters in zaurus gpio .desc
Pavel Machek wrote: From: Cyril Hrubis me...@ucw.cz Somehow, Some = my Evolution Mail I remember that I prepared a patch and fixed capitalization of these strings in the mail body in the last minute before sending. strange characters made their way zaurus gpio .desc fields. Fix it. Signed-off-by: Pavel Machek pa...@ucw.cz Acked-by: Stanislav Brabec u...@penguin.cz Hint: If you use Evolution Mail for sending mails, never edit anything inside inlined patch and never use old mail as a template, otherwise Evolution Mail will include invisible characters to your mail. Let's see whether it is fixed in the evolution-2.28. Stanislav Brabec http://www.penguin.cz/~utx/zaurus ___ Zaurus-devel mailing list Zaurus-devel@lists.linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/zaurus-devel
