Discussion:
2.6.37
Lars-Peter Clausen
2011-01-05 19:26:10 UTC
Permalink
Hi

I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].

There is not much new or fancy this time. Most of the changes made were fixes for
regressions introduced in upstream.

The major non-fix changes are:
* I've added support for the bq27000 to the bq27x00 driver and dropped the old
bq27000 driver. This should make getting the driver upstream easier.
* The pcf50633 has gained genirq support instead of implementing its own irq api for
child devices. But apart from that there are now statistics about the the pcf50633
in /proc/interrupts this should not have any visible changes.
The plan is to add support for enabling wakeup on a per device basis that can be
changed at runtime, so for example the power button could be disabled as a wakeup
source.
* One WSOD fix in the jbt67k4 driver.

The plan is now to send the battery, sound and pmu patches and some of the machine
patches upstream after the merged window for 2.6.38 has closed, so that they might
appear in 2.6.39.
So it would be good if the patches could get some more testing before.

- - Lars

[1]http://git.openmoko.org/?p=kernel.git;a=shortlog;h=refs/heads/om-gta02-2.6.37
Radek Polak
2011-01-06 09:29:42 UTC
Permalink
Post by Lars-Peter Clausen
Hi
I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].
Great, thanks a lot!

I would like to test it, but fetching from openmoko git gives me:

git.openmoko.org[0: 88.198.160.201]: errno=Connection refused

Can anybody from openmoko take a look at it? Or maybe could you push it to
some other git server?

Thanks once more for your work

Radek
Lars-Peter Clausen
2011-01-06 12:19:44 UTC
Permalink
Post by Radek Polak
Post by Lars-Peter Clausen
Hi
I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].
Great, thanks a lot!
git.openmoko.org[0: 88.198.160.201]: errno=Connection refused
Can anybody from openmoko take a look at it? Or maybe could you push it to
some other git server?
Thanks once more for your work
Radek
Hi

Cloning the repo via http works (but is rather slow).
git clone http://git.openmoko.org/git/kernel.git

- - Lars
Lars-Peter Clausen
2011-01-06 12:36:11 UTC
Permalink
Post by Lars-Peter Clausen
Post by Radek Polak
Post by Lars-Peter Clausen
Hi
I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].
Great, thanks a lot!
git.openmoko.org[0: 88.198.160.201]: errno=Connection refused
Can anybody from openmoko take a look at it? Or maybe could you push it to
some other git server?
Thanks once more for your work
Radek
Hi
Cloning the repo via http works (but is rather slow).
git clone http://git.openmoko.org/git/kernel.git
- Lars
Hi

Thanks to roh access via the git protocoll works again.
git clone git://git.openmoko.org/git/kernel.git

- - Lars
Radek Polak
2011-01-07 22:50:29 UTC
Permalink
Post by Lars-Peter Clausen
I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].
I have now ported most of 2.6.34 patches from my qtmoko git on to of this. The
repository is here [1].

I dont have problem with keeping patches on top openmoko git, but maybe it
would make sence to cherry-pick some of them from mine git. Here is my list of
patches that are IMO most important:

1/ high power consumption in suspend - without this FR is really not usable as
phone, battery dies very fast:
https://github.com/radekp/linux-2.6/commit/64929b7ed0f89e94a97f815380faea844d28f6d1

2/ headset jack detection support:
https://github.com/radekp/linux-2.6/commit/4e6ab66435c6e3679134fdd7c4eeea58f6022f38

3/ fix WS on boot when using qi/uboot with 242 glamo timings (nowadays nearly
everyone uses this faster bootloaders)
https://github.com/radekp/linux-2.6/commit/5a6bd71ba228b8613137241898038a3c0354327c

4/ delay in ar6000k, without it wlan wont survive suspend/resume. Author is
Gennady not me (forgot --author):
https://github.com/radekp/linux-2.6/commit/4ec5000cd425b60394d433af577e98019b103fa5

Other patches [2] are also important, without them FR is quite useless as
phone, but i think these 4 are the first candidates to look at.

Otherwise I havent tested new kernel very much yet, but it looks quite usable.
Things that i tested and are OK:

- touchscreen, bluetooh, wifi, keys, sound, gsm calls, usb ethernet,
suspend/resume, battery (checked just current_now sysfs node).

Interesting thing about current_now is that i had seen several times after
resume value 5mA. I never seen so small value with previous kernels. Usual
value is 12mA. I wonder if we are eating less power now or displaying wrong
value ;-)

I also had some problems, but after rebuilding from scratch they seems to be
gone. So until now there are no regressions, which is really nice.

Thanks Lars for new kernel and others for help.

Regards

Radek


[1] https://github.com/radekp/linux-2.6/tree/qtmoko-v32.1
[2] https://github.com/radekp/linux-2.6/commits/qtmoko-v32.1
Petr Vanek
2011-01-08 09:50:07 UTC
Permalink
Post by Radek Polak
Interesting thing about current_now is that i had seen several times
after resume value 5mA. I never seen so small value with previous
kernels. Usual value is 12mA. I wonder if we are eating less power now
or displaying wrong value ;-)
Hi Radek,

i have the same observation on 386 based machine - last night i tested
2.6.37 on my HP laptop based server here. Unfortunately, i have also
tweaked bios settings and turned off several unneeded hw features (usb,
pcmci etc) so i don't know whether this wasn t the big part of the
reason, but power consumption went down significantly.

Petr
Petr Vanek
2011-01-08 10:32:26 UTC
Permalink
On Sat, 8 Jan 2011 10:50:07 +0100
Post by Petr Vanek
Post by Radek Polak
Interesting thing about current_now is that i had seen several times
after resume value 5mA. I never seen so small value with previous
kernels. Usual value is 12mA. I wonder if we are eating less power now
or displaying wrong value ;-)
Hi Radek,
i have the same observation on 386 based machine - last night i tested
2.6.37 on my HP laptop based server here. Unfortunately, i have also
tweaked bios settings and turned off several unneeded hw features (usb,
pcmci etc) so i don't know whether this wasn t the big part of the
reason, but power consumption went down significantly.
Radek,

still on that x86 machine, i can see:

2.6.26 19W
2.6.30 1.9W
2.6.37 1.7W

so it seems like wrong units...?

Petr
Radek Polak
2011-01-08 10:43:04 UTC
Permalink
Post by Petr Vanek
2.6.26 19W
2.6.30 1.9W
2.6.37 1.7W
so it seems like wrong units...?
Interesting is that when FR is out of suspend, the current_now values look ok
- i am getting something around 280mA - same as in previous versions. Best
would be to keep FR in suspend and check battery every day. If the current_now
value is correct it should last without charging for 10 days. I have only
verified just 10 hours now ;-)

Regards

Radek
Timo Juhani Lindfors
2011-01-08 14:44:14 UTC
Permalink
Hi Lars and Radek,
Post by Radek Polak
I have now ported most of 2.6.34 patches from my qtmoko git on to of this. The
repository is here [1].
thanks a lot for your efforts! Here's a preliminary test report. I'm
running qtmoko-v32.1 branch

$ git log --oneline om-2.6.37..qtmoko-v32.1
84af470 Revert input version as tslib compiled against older
c90c0d0 GTA02 config - bump version to v32
d366e03 GTA02 config - compile new battery driver
0a3c7cf GTA02 config - regenerate for 2.6.37
a849cbc GTA02 config from qtmoko-v31 (2.6.34 based)
ff44a38 Use 100 as HZ value on S3C24XX
4e6ab66 wm8753: use snd_soc_jack on neo1973
b6f1cb1 Force GPS power up on resume if it were powered up on suspend
1bb67b1 s3c2410_ts: jitter less touchscreen for glamo, version 4
71e0285 Openmoko resume reason sysfs node ported from 2.6.29
efcd40e Rename /dev/s3c2410_serialXXX to /dev/ttySACXXX
5a6bd71 glamo-display: fix WSOD for 242 timming
373c7d7 Enable powering off after 8s POWER press
64929b7 Fix high power consumption in suspend
3c96492 tslib relies on ts pressures events so this hack is needed to get tslib stuff working
4ec5000 ar6000_delay.patch
a29b83e usbhost.patch
0756a5e touchscreen: ignore unexpected interrupts
4b9b0a2 wm8753: fix build with gcc-4.4.2, which works ok with 4.1.2

with a few extra patches:

$ git log --oneline qtmoko-v32.1..lindi-qtmoko-v32.1
ba97d73 remove -v32 localversion
c7064e8 Port ramconsole patch to 2.6.34
d44c1e2 Add CONFIG_OPENMOKO_RESUME_REASON=m
b36cab3 add symlink to config

and u-boot stable branch with a few extra patches:

$ git log --oneline stable..lindi
5328070 bugfix previous patch, enable watchdog only for resume, not boot
47e4c33 buildfix previous patch
abb1f1c experiment: explicitely start watchdog on boot/resume
cc1e94f experiment: do not disable watchdog on boot/resume
9c2b2be Do power on LDO5 (GPS) regulator and do not setup all serial's GPIOs at all on boot
d4a3860 Kindly ask u-boot do not touch serials and serial's gpio setup
4ae4060 Turn vibrator on and aux off on resume.
f4cd104 Add support for forcing charging at maximum current (usually 500 mA). This is useful if the battery is fully depleted and one wants to stay in the boot loader waiting for the battery to charge.

First I tested all features offered by omhacks. I noticed the
following problems:

1) om screen resolution

does not work since

/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.9/glamo3362.0/glamo-spi-gpio.0/spi2.0/state

does not exist. Is there some other sysfs node for toggling between qvga and vga?

2) om battery charger-limit

does not work since neither

/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/chg_curlim

nor

/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc/chg_curlim

exists. Is the fix just to use

/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc.0/chg_curlim?

Could we make these patches more stable somehow?

3) huawei 3G dongle does not switch to modem mode:

Jan 8 15:54:59 ginger kernel: [ 1751.490000] usb 1-2: new full speed USB device using s3c2410-ohci and address 39
Jan 8 15:54:59 ginger kernel: [ 1751.670000] usb 1-2: New USB device found, idVendor=12d1, idProduct=1001
Jan 8 15:54:59 ginger kernel: [ 1751.670000] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Jan 8 15:54:59 ginger kernel: [ 1751.670000] usb 1-2: Product: HUAWEI Mobile
Jan 8 15:54:59 ginger kernel: [ 1751.670000] usb 1-2: Manufacturer: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Jan 8 15:54:59 ginger kernel: [ 1751.670000] usb 1-2: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Jan 8 15:54:59 ginger kernel: [ 1751.900000] usbcore: registered new interface driver ub
Jan 8 15:54:59 ginger kernel: [ 1752.340000] SCSI subsystem initialized
Jan 8 15:55:00 ginger kernel: [ 1752.540000] Initializing USB Mass Storage driver...
Jan 8 15:55:00 ginger kernel: [ 1752.540000] usbcore: registered new interface driver usb-storage
Jan 8 15:55:00 ginger kernel: [ 1752.540000] USB Mass Storage support registered.
$ ls -l /dev/ttyUSB*
ls: cannot access /dev/ttyUSB*: No such file or directory

Adding "option" to /etc/modules fixed this -- should it get loaded
automatically? Even after that

Jan 8 15:59:45 ginger kernel: [ 2037.460000] usbcore: registered new interface driver usbserial
Jan 8 15:59:45 ginger kernel: [ 2037.460000] USB Serial support registered for generic
Jan 8 15:59:45 ginger kernel: [ 2037.460000] usbcore: registered new interface driver usbserial_generic
Jan 8 15:59:45 ginger kernel: [ 2037.460000] usbserial: USB Serial Driver core
Jan 8 15:59:45 ginger kernel: [ 2037.650000] USB Serial support registered for GSM modem (1-port)
Jan 8 15:59:45 ginger kernel: [ 2037.650000] usbcore: registered new interface driver option
Jan 8 15:59:45 ginger kernel: [ 2037.650000] option: v0.7.2:USB Driver for GSM modems

I get no /dev/ttyUSB*.

4) om usb charger-limit

does not work since

/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim

does not exist. Should I again use

/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc.0/usb_curlim

instead?

5) udev rule

SUBSYSTEM=="input", ATTRS{name}=="lis302-1 (top)", SYMLINK+="accelerometer-top"

does not find accelerometers. No node in /dev/input seems to be an
accelerometer.

6) (as I reported earlier) when I touch the screen to wake it up from
dpms sleep I see white screen for a few milliseconds. I'm using
xserver-xorg-video-fbdev.
Lars-Peter Clausen
2011-01-08 18:47:15 UTC
Permalink
Hi
Post by Timo Juhani Lindfors
Hi Lars and Radek,
Post by Radek Polak
I have now ported most of 2.6.34 patches from my qtmoko git on to of this. The
repository is here [1].
thanks a lot for your efforts! Here's a preliminary test report. I'm
running qtmoko-v32.1 branch
Thanks for testing :)
Post by Timo Juhani Lindfors
$ git log --oneline om-2.6.37..qtmoko-v32.1
84af470 Revert input version as tslib compiled against older
c90c0d0 GTA02 config - bump version to v32
d366e03 GTA02 config - compile new battery driver
0a3c7cf GTA02 config - regenerate for 2.6.37
a849cbc GTA02 config from qtmoko-v31 (2.6.34 based)
ff44a38 Use 100 as HZ value on S3C24XX
4e6ab66 wm8753: use snd_soc_jack on neo1973
b6f1cb1 Force GPS power up on resume if it were powered up on suspend
1bb67b1 s3c2410_ts: jitter less touchscreen for glamo, version 4
71e0285 Openmoko resume reason sysfs node ported from 2.6.29
efcd40e Rename /dev/s3c2410_serialXXX to /dev/ttySACXXX
5a6bd71 glamo-display: fix WSOD for 242 timming
373c7d7 Enable powering off after 8s POWER press
64929b7 Fix high power consumption in suspend
3c96492 tslib relies on ts pressures events so this hack is needed to get tslib
stuff working
Post by Timo Juhani Lindfors
4ec5000 ar6000_delay.patch
a29b83e usbhost.patch
0756a5e touchscreen: ignore unexpected interrupts
4b9b0a2 wm8753: fix build with gcc-4.4.2, which works ok with 4.1.2
$ git log --oneline qtmoko-v32.1..lindi-qtmoko-v32.1
ba97d73 remove -v32 localversion
c7064e8 Port ramconsole patch to 2.6.34
d44c1e2 Add CONFIG_OPENMOKO_RESUME_REASON=m
b36cab3 add symlink to config
$ git log --oneline stable..lindi
5328070 bugfix previous patch, enable watchdog only for resume, not boot
47e4c33 buildfix previous patch
abb1f1c experiment: explicitely start watchdog on boot/resume
cc1e94f experiment: do not disable watchdog on boot/resume
9c2b2be Do power on LDO5 (GPS) regulator and do not setup all serial's GPIOs at all on boot
d4a3860 Kindly ask u-boot do not touch serials and serial's gpio setup
4ae4060 Turn vibrator on and aux off on resume.
f4cd104 Add support for forcing charging at maximum current (usually 500 mA).
This is useful if the battery is fully depleted and one wants to stay in the boot
loader waiting for the battery to charge.
Post by Timo Juhani Lindfors
First I tested all features offered by omhacks. I noticed the
1) om screen resolution
does not work since
/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.9/glamo3362.0/glamo-spi-gpio.0/spi2.0/state
Post by Timo Juhani Lindfors
does not exist. Is there some other sysfs node for toggling between qvga and vga?
I seriously wonder where you always dig these paths up.

A good path to use for changing the resolution is

/sys/class/lcd/jbt6k74-lcd/device/resolution
Post by Timo Juhani Lindfors
2) om battery charger-limit
does not work since neither
/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/chg_curlim
nor
/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc/chg_curlim
exists. Is the fix just to use
/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc.0/chg_curlim?
I've pushed an update which should change
the device name back to pcf50633-mbc instead of pcf50633-mbc.0

But you should really use

/sys/bus/platform/devices/pcf50633-mbc/chr_curlim

as it should work across all kernel versions.
Post by Timo Juhani Lindfors
Could we make these patches more stable somehow?
Jan 8 15:54:59 ginger kernel: [ 1751.490000] usb 1-2: new full speed USB device
using s3c2410-ohci and address 39
Post by Timo Juhani Lindfors
Jan 8 15:54:59 ginger kernel: [ 1751.670000] usb 1-2: New USB device found,
idVendor=12d1, idProduct=1001
Mfr=1, Product=2, SerialNumber=1
Post by Timo Juhani Lindfors
Jan 8 15:54:59 ginger kernel: [ 1751.670000] usb 1-2: Product: HUAWEI Mobile
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Post by Timo Juhani Lindfors
Jan 8 15:54:59 ginger kernel: [ 1751.900000] usbcore: registered new interface driver ub
Jan 8 15:54:59 ginger kernel: [ 1752.340000] SCSI subsystem initialized
Jan 8 15:55:00 ginger kernel: [ 1752.540000] Initializing USB Mass Storage driver...
Jan 8 15:55:00 ginger kernel: [ 1752.540000] usbcore: registered new interface
driver usb-storage
Post by Timo Juhani Lindfors
Jan 8 15:55:00 ginger kernel: [ 1752.540000] USB Mass Storage support registered.
$ ls -l /dev/ttyUSB*
ls: cannot access /dev/ttyUSB*: No such file or directory
Adding "option" to /etc/modules fixed this -- should it get loaded
automatically? Even after that
Jan 8 15:59:45 ginger kernel: [ 2037.460000] usbcore: registered new interface
driver usbserial
Post by Timo Juhani Lindfors
Jan 8 15:59:45 ginger kernel: [ 2037.460000] USB Serial support registered for generic
Jan 8 15:59:45 ginger kernel: [ 2037.460000] usbcore: registered new interface
driver usbserial_generic
Post by Timo Juhani Lindfors
Jan 8 15:59:45 ginger kernel: [ 2037.460000] usbserial: USB Serial Driver core
Jan 8 15:59:45 ginger kernel: [ 2037.650000] USB Serial support registered for
GSM modem (1-port)
Post by Timo Juhani Lindfors
Jan 8 15:59:45 ginger kernel: [ 2037.650000] usbcore: registered new interface
driver option
Post by Timo Juhani Lindfors
Jan 8 15:59:45 ginger kernel: [ 2037.650000] option: v0.7.2:USB Driver for GSM modems
I get no /dev/ttyUSB*.
4) om usb charger-limit
does not work since
/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-mbc/usb_curlim
does not exist. Should I again use
/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc.0/usb_curlim
instead?
Same here:
/sys/bus/platform/devices/pcf50633-mbc/usb_curlim
Post by Timo Juhani Lindfors
5) udev rule
SUBSYSTEM=="input", ATTRS{name}=="lis302-1 (top)", SYMLINK+="accelerometer-top"
does not find accelerometers. No node in /dev/input seems to be an
accelerometer.
6) (as I reported earlier) when I touch the screen to wake it up from
dpms sleep I see white screen for a few milliseconds. I'm using
xserver-xorg-video-fbdev.
Timo Juhani Lindfors
2011-01-08 19:55:22 UTC
Permalink
Post by Lars-Peter Clausen
A good path to use for changing the resolution is
/sys/class/lcd/jbt6k74-lcd/device/resolution
Thanks.
Post by Lars-Peter Clausen
I've pushed an update which should change
the device name back to pcf50633-mbc instead of pcf50633-mbc.0
But you should really use
/sys/bus/platform/devices/pcf50633-mbc/chr_curlim
as it should work across all kernel versions.
Hmm, was there a typo?

$ ls -l /sys/bus/platform/devices/pcf50633-mbc/chr_curlim
ls: cannot access /sys/bus/platform/devices/pcf50633-mbc/chr_curlim: No such file or directory
Post by Lars-Peter Clausen
Post by Timo Juhani Lindfors
/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc.0/usb_curlim
instead?
/sys/bus/platform/devices/pcf50633-mbc/usb_curlim
$ ls -l /sys/bus/platform/devices/pcf50633-mbc/usb_curlim
ls: cannot access /sys/bus/platform/devices/pcf50633-mbc/usb_curlim: No such file or directory
Lars-Peter Clausen
2011-01-08 20:02:25 UTC
Permalink
Post by Timo Juhani Lindfors
Post by Lars-Peter Clausen
A good path to use for changing the resolution is
/sys/class/lcd/jbt6k74-lcd/device/resolution
Thanks.
Post by Lars-Peter Clausen
I've pushed an update which should change
the device name back to pcf50633-mbc instead of pcf50633-mbc.0
But you should really use
/sys/bus/platform/devices/pcf50633-mbc/chr_curlim
as it should work across all kernel versions.
Hmm, was there a typo?
$ ls -l /sys/bus/platform/devices/pcf50633-mbc/chr_curlim
ls: cannot access /sys/bus/platform/devices/pcf50633-mbc/chr_curlim: No such file
or directory
Post by Timo Juhani Lindfors
Post by Lars-Peter Clausen
Post by Timo Juhani Lindfors
/sys/devices/platform/s3c2440-i2c/i2c-0/0-0073/pcf50633-mbc.0/usb_curlim
instead?
/sys/bus/platform/devices/pcf50633-mbc/usb_curlim
$ ls -l /sys/bus/platform/devices/pcf50633-mbc/usb_curlim
ls: cannot access /sys/bus/platform/devices/pcf50633-mbc/usb_curlim: No such file
or directory

You need this patch:
http://git.openmoko.org/?p=kernel.git;a=commit;h=bb77a81

Otherwise it is still /sys/bus/platform/devices/pcf50633-mbc.0/

And it is chg_curlim instead of chr_curlim
Timo Juhani Lindfors
2011-01-08 20:16:14 UTC
Permalink
Post by Lars-Peter Clausen
A good path to use for changing the resolution is
/sys/class/lcd/jbt6k74-lcd/device/resolution
$ cat /sys/class/lcd/jbt6k74-lcd/device/resolution
vga

but previously it returned "normal" or "qvga-normal". Should vga be
interpreted as "normal" now?
Lars-Peter Clausen
2011-01-08 20:24:12 UTC
Permalink
Post by Timo Juhani Lindfors
Post by Lars-Peter Clausen
A good path to use for changing the resolution is
/sys/class/lcd/jbt6k74-lcd/device/resolution
$ cat /sys/class/lcd/jbt6k74-lcd/device/resolution
vga
but previously it returned "normal" or "qvga-normal". Should vga be
interpreted as "normal" now?
valid values are "vga" and "qvga".
Timo Juhani Lindfors
2011-01-08 20:38:06 UTC
Permalink
Post by Lars-Peter Clausen
Post by Timo Juhani Lindfors
but previously it returned "normal" or "qvga-normal". Should vga be
interpreted as "normal" now?
valid values are "vga" and "qvga".
Ok hmm. So to set 240x320 mode I should write "qvga" with 2.6.37 and
"qvga-normal" with 2.6.29?

Is there some way to probe for valid values at runtime or should I
just parse uname -r? :-(
Lars-Peter Clausen
2011-01-09 17:10:21 UTC
Permalink
Post by Timo Juhani Lindfors
Post by Lars-Peter Clausen
Post by Timo Juhani Lindfors
but previously it returned "normal" or "qvga-normal". Should vga be
interpreted as "normal" now?
valid values are "vga" and "qvga".
Ok hmm. So to set 240x320 mode I should write "qvga" with 2.6.37 and
"qvga-normal" with 2.6.29?
Is there some way to probe for valid values at runtime or should I
just parse uname -r? :-(
Ah, ok you are still using 2.6.29.
The path I posted only works with the 2.6.3x kernels.
So the "resolution" sysfs attribute expects either qvga or vga and
the the state sysfs attribute expects normal or normal-qvga.

- - Lars
Timo Juhani Lindfors
2011-01-18 17:13:12 UTC
Permalink
Post by Lars-Peter Clausen
Ah, ok you are still using 2.6.29.
I'm testing various different kernels and I'd like to keep omhacks
compatible with as many of them as reasonably possible. I'm still
using 2.6.29 as my "stable" boot menu entry followed by 2.6.34 as
"testing" and 2.6.37 as "experimental".
Post by Lars-Peter Clausen
The path I posted only works with the 2.6.3x kernels.
Sorry, I think I missed this patch when I read your mail for the first
time and now I can't find it anymore. I clicked through the emails at

http://lists.openmoko.org/pipermail/openmoko-kernel/2011-January/thread.html

but can't find it. Which mail did I miss?
Post by Lars-Peter Clausen
So the "resolution" sysfs attribute expects either qvga or vga and
the the state sysfs attribute expects normal or normal-qvga.
Can you recommend some strategy for supporting both 2.6.29 and 2.6.3x
in omhacks? The first idea is the following pseudocode:

def rotate(idx):
if read("resolution") in ["vga", "qvga"]:
new_api=True
if new_api:
write("resolution", ["vga", "qvga"][idx])
else
write("resolution", ["normal", "normal-qvga"][idx])
Lars-Peter Clausen
2011-01-18 17:20:33 UTC
Permalink
Post by Timo Juhani Lindfors
Post by Lars-Peter Clausen
Ah, ok you are still using 2.6.29.
I'm testing various different kernels and I'd like to keep omhacks
compatible with as many of them as reasonably possible. I'm still
using 2.6.29 as my "stable" boot menu entry followed by 2.6.34 as
"testing" and 2.6.37 as "experimental".
Post by Lars-Peter Clausen
The path I posted only works with the 2.6.3x kernels.
Sorry, I think I missed this patch when I read your mail for the first
time and now I can't find it anymore. I clicked through the emails at
http://lists.openmoko.org/pipermail/openmoko-kernel/2011-January/thread.html
but can't find it. Which mail did I miss?
Are you looking for this one?
Post by Timo Juhani Lindfors
Post by Lars-Peter Clausen
So the "resolution" sysfs attribute expects either qvga or vga and
the the state sysfs attribute expects normal or normal-qvga.
Can you recommend some strategy for supporting both 2.6.29 and 2.6.3x
new_api=True
write("resolution", ["vga", "qvga"][idx])
else
write("resolution", ["normal", "normal-qvga"][idx])
I guess the best would be:

if file_exists("/sys/class/lcd/jbt6k74/device/resolution"):
new_api = True
else
new_api = False

def rotate(idx):
if new_api:
write("resolution", ["vga", "qvga"][idx])
else
write("state", ["normal", "normal-qvga"][idx])


- - Lars
Timo Juhani Lindfors
2011-02-16 07:53:11 UTC
Permalink
Post by Lars-Peter Clausen
new_api = True
else
new_api = False
write("resolution", ["vga", "qvga"][idx])
else
write("state", ["normal", "normal-qvga"][idx])
omhacks 0.13-1 in debian unstable now has similar logic. It'll be
migrated to wheezy in two days.
Radek Polak
2011-01-09 18:46:12 UTC
Permalink
Post by Timo Juhani Lindfors
5) udev rule
SUBSYSTEM=="input", ATTRS{name}=="lis302-1 (top)",
SYMLINK+="accelerometer-top"
does not find accelerometers. No node in /dev/input seems to be an
accelerometer.
I have not ported the accelerometer patch yet. I was hoping there is upstream
driver, but it seems there is not one included yet. I will port it later when
i have some more time, since it's non trivial.

Regards

Radek
Riccardo Magliocchetti
2011-01-10 09:15:17 UTC
Permalink
Hi,
Post by Radek Polak
Post by Timo Juhani Lindfors
5) udev rule
SUBSYSTEM=="input", ATTRS{name}=="lis302-1 (top)",
SYMLINK+="accelerometer-top"
does not find accelerometers. No node in /dev/input seems to be an
accelerometer.
I have not ported the accelerometer patch yet. I was hoping there is upstream
driver, but it seems there is not one included yet. I will port it later when
i have some more time, since it's non trivial.
Isn't it drivers/hwmon/lis3lv02d* ?.

BTW, does anyone have tried the ath6kl wifi driver in staging?

riccardo
Fox Mulder
2011-01-10 16:41:36 UTC
Permalink
Post by Riccardo Magliocchetti
Hi,
Post by Radek Polak
Post by Timo Juhani Lindfors
5) udev rule
SUBSYSTEM=="input", ATTRS{name}=="lis302-1 (top)",
SYMLINK+="accelerometer-top"
does not find accelerometers. No node in /dev/input seems to be an
accelerometer.
I have not ported the accelerometer patch yet. I was hoping there is upstream
driver, but it seems there is not one included yet. I will port it later when
i have some more time, since it's non trivial.
Isn't it drivers/hwmon/lis3lv02d* ?.
LIS3LV02D* and LIS302D* have different internel settings and features.
So they are not compatible to each other without code modifications.
I know this because i used the LIS3LV02DL in a sample microcontroller
application.

Ciao,
Rainer
Joerg Reisenweber
2011-04-14 09:04:02 UTC
Permalink
lis3lv02d is completely borked. It just does poll, no support for IRQ, which
means it will drain your battery in no time. They did that mistake to use that
borked driver on meego

/j
Alan Cox
2011-04-14 09:19:58 UTC
Permalink
On Thu, 14 Apr 2011 11:04:02 +0200
Post by Joerg Reisenweber
lis3lv02d is completely borked. It just does poll, no support for IRQ, which
means it will drain your battery in no time. They did that mistake to use that
borked driver on meego
If you are using it for event sensing only then you want to send patches
to update the driver for it..
Radek Polak
2011-04-15 07:20:27 UTC
Permalink
Post by Alan Cox
On Thu, 14 Apr 2011 11:04:02 +0200
Post by Joerg Reisenweber
lis3lv02d is completely borked. It just does poll, no support for IRQ,
which means it will drain your battery in no time. They did that mistake
to use that borked driver on meego
If you are using it for event sensing only then you want to send patches
to update the driver for it..
Just for info. I have backported lis302dl driver from andy-tracking to our
current 2.6.37:

https://github.com/radekp/linux-2.6/commit/992c53974c9b7c9a53798c5d8e4e6e9ef1bce4ff
https://github.com/radekp/linux-2.6/commit/6cb43d0551194815c5fd51e93dfac92245b5a15c

It seems to work just fine on my phone.

Regards

Radek

Timo Juhani Lindfors
2011-01-08 20:04:05 UTC
Permalink
Hi,
Post by Lars-Peter Clausen
I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].
my FR woke due to rtc alarm, tried to suspend again but it failed with
no obvious reason:

Jan 8 21:00:00 ginger logger: susp.real: resuming (reason EINT09_PMU:rtc_alarm) (temperature 24.60) (consumption 20349) (energy 76) (pos na)
Jan 8 21:00:00 ginger logger: susp.real:80
Jan 8 21:00:00 ginger logger: susp.real:104
Jan 8 21:00:00 ginger logger: susp.real:106
Jan 8 21:00:00 ginger logger: susp.real:48
Jan 8 21:00:00 ginger logger: susp.real:50
Jan 8 21:00:02 ginger kernel: [ 5092.990000] PM: Syncing filesystems ... done.
Jan 8 21:00:03 ginger kernel: [ 5094.980000] Freezing user space processes ... (elapsed 0.02 seconds) done.
Jan 8 21:00:03 ginger kernel: [ 5095.000000] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Jan 8 21:00:03 ginger kernel: [ 5095.020000] Suspending console(s) (use no_console_suspend to debug)
Jan 8 21:00:03 ginger kernel: [ 5095.030000] jbt6k74 spi2.0: suspended
Jan 8 21:00:03 ginger kernel: [ 5095.050000] glamo-mci glamo-mci.0: glamo_mci_set_ios: power down.
Jan 8 21:00:03 ginger kernel: [ 5095.050000] wake enabled for irq 17
Jan 8 21:00:03 ginger kernel: [ 5095.070000] gta02-pm-bt gta02-pm-bt.0: __gta02_pm_bt_toggle_radio 0
Jan 8 21:00:03 ginger kernel: [ 5095.070000] PM: suspend of devices complete after 50.000 msecs
Jan 8 21:00:03 ginger kernel: [ 5095.070000] PM: late suspend of devices complete after 0.001 msecs
Jan 8 21:00:03 ginger kernel: [ 5095.070000] PM: early resume of devices complete after 0.001 msecs
Jan 8 21:00:03 ginger kernel: [ 5095.070000] s3c2410-wdt: watchdog enabled
Jan 8 21:00:03 ginger kernel: [ 5095.070000] s3c24xx-nand s3c2440-nand: Tacls=1, 10ns Twrph0=3 30ns, Twrph1=2 20ns
Jan 8 21:00:03 ginger kernel: [ 5095.070000] s3c-i2c s3c2440-i2c: slave address 0x10
Jan 8 21:00:03 ginger kernel: [ 5095.070000] s3c-i2c s3c2440-i2c: bus frequency set to 97 KHz
Jan 8 21:00:03 ginger kernel: [ 5095.070000] gta02-pm-bt gta02-pm-bt.0: __gta02_pm_bt_toggle_radio 0
Jan 8 21:00:03 ginger kernel: [ 5095.100000] wake disabled for irq 17
Jan 8 21:00:03 ginger kernel: [ 5095.180000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 0kHz div=0 (req: 0kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.200000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 399kHz div=0 (req: 400kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.220000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 399kHz div=0 (req: 400kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.230000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 399kHz div=0 (req: 400kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.230000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 399kHz div=0 (req: 400kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.250000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 399kHz div=0 (req: 400kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.260000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 399kHz div=0 (req: 400kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.260000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 16373kHz div=0 (req: 21000kHz). Bus width=0
Jan 8 21:00:03 ginger kernel: [ 5095.270000] glamo-mci glamo-mci.0: powered (vdd = 15) clk: 16373kHz div=0 (req: 21000kHz). Bus width=2
Jan 8 21:00:03 ginger kernel: [ 5095.270000] jbt6k74 spi2.0: starting resume: 2
Jan 8 21:00:03 ginger kernel: [ 5095.420000] jbt6k74 spi2.0: resumed: 2
Jan 8 21:00:03 ginger kernel: [ 5095.420000] soc-audio soc-audio: resume work item may be lost
Jan 8 21:00:03 ginger kernel: [ 5095.420000] PM: resume of devices complete after 353.891 msecs
Jan 8 21:00:03 ginger kernel: [ 5095.420000] Restarting tasks ... done.
Jan 8 21:00:03 ginger logger: susp.real:55
Jan 8 21:00:04 ginger logger: susp.real:57
Jan 8 21:00:04 ginger logger: susp.real:64
Jan 8 21:00:04 ginger logger: susp.real:70
Jan 8 21:00:04 ginger logger: susp.real:72
Jan 8 21:00:04 ginger logger: susp.real:75
Jan 8 21:00:04 ginger logger: susp.real: resuming (reason ) (temperature 24.60) (consumption 20349) (energy 76) (pos na)

Any idea what's going on here? The resume reason driver just reads
from GSTATUS4.
Gennady Kupava
2011-01-16 19:28:45 UTC
Permalink
Hi, Lars-Peter & list.
Post by Lars-Peter Clausen
I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].
First of all, thanks for your work!

Here i have quite big problem with this kernel -> ubi doesn't want to
work. It even can't mount rootfs (which is UBIfs), because 'UBI is
read-only". It worked well with same options with 2.6.34.

Booted from sd and attempting to mount it manually in following way:

#ubiattach -m 6 -O 2048
UBI device number 0, total 1973 LEBs (250523648 bytes, 238.9 MiB),
available 3 LEBs (380928 bytes, 372.0 KiB), LEB size 126976 bytes (124.0
KiB)

#mount -t ubifs ubi0:om-gta02-rootfs /mnt/flash/ -o
compr=zlib,no_chk_data_crc
mount: block device ubi0:om-gta02-rootfs is write-protected, mounting
read-only

I am getting following kernel errors:

92.660000] UBI: attaching mtd6 to ubi0
[ 92.670000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 92.680000] UBI: logical eraseblock size: 126976 bytes
[ 92.690000] UBI: smallest flash I/O unit: 2048
[ 92.700000] UBI: sub-page size: 512
[ 92.710000] UBI: VID header offset: 2048 (aligned 2048)
[ 92.720000] UBI: data offset: 4096
[ 92.770000] uncorrectable error :
[ 92.780000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 64 bytes from PEB 255:0, read 64 bytes
[ 92.790000] uncorrectable error :
[ 92.790000] uncorrectable error :
[ 92.800000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 512 bytes from PEB 255:2048, read 512 bytes
[ 92.860000] uncorrectable error :
[ 92.860000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 64 bytes from PEB 534:0, read 64 bytes
[ 92.870000] uncorrectable error :
[ 92.870000] uncorrectable error :
[ 92.890000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 512 bytes from PEB 534:2048, read 512 bytes
[ 93.180000] uncorrectable error :
[ 93.180000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 64 bytes from PEB 1553:0, read 64 bytes
[ 93.190000] uncorrectable error :
[ 93.190000] uncorrectable error :
[ 93.200000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 512 bytes from PEB 1553:2048, read 512 bytes
[ 93.320000] UBI: max. sequence number: 3382
[ 93.370000] UBI: attached mtd6 to ubi0
[ 93.380000] UBI: MTD device name: "rootfs"
[ 93.390000] UBI: MTD device size: 246 MiB
[ 93.400000] UBI: number of good PEBs: 1973
[ 93.410000] UBI: number of bad PEBs: 0
[ 93.420000] UBI: number of corrupted PEBs: 0
[ 93.430000] UBI: max. allowed volumes: 128
[ 93.440000] UBI: wear-leveling threshold: 4096

And so on (see full log in attachment)

Same partition working well with .34 kernel

My /proc/cmdline:
console=tty0 loglevel=8 regular_boot glamo_mci.sd_max_clk=15000000
mem=127M panic=20 root=/dev/mmcblk0p2 rootwait
mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(u-boot),0x00040000(u-boot_env),0x00800000(kernel),0x000a0000(splash),0x00040000(factory),0x0f6a0000(rootfs) ro

.config is in attachment. i tried radek's config too - same story.
Lars-Peter Clausen
2011-01-17 18:16:13 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Gennady Kupava
Hi, Lars-Peter & list.
Post by Lars-Peter Clausen
I've just pushed the 2.6.37 trees for the GTA02 to the openmoko git kernel repo[1].
First of all, thanks for your work!
Here i have quite big problem with this kernel -> ubi doesn't want to
work. It even can't mount rootfs (which is UBIfs), because 'UBI is
read-only". It worked well with same options with 2.6.34.
#ubiattach -m 6 -O 2048
UBI device number 0, total 1973 LEBs (250523648 bytes, 238.9 MiB),
available 3 LEBs (380928 bytes, 372.0 KiB), LEB size 126976 bytes (124.0
KiB)
#mount -t ubifs ubi0:om-gta02-rootfs /mnt/flash/ -o
compr=zlib,no_chk_data_crc
mount: block device ubi0:om-gta02-rootfs is write-protected, mounting
read-only
92.660000] UBI: attaching mtd6 to ubi0
[ 92.670000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
[ 92.680000] UBI: logical eraseblock size: 126976 bytes
[ 92.690000] UBI: smallest flash I/O unit: 2048
[ 92.700000] UBI: sub-page size: 512
[ 92.710000] UBI: VID header offset: 2048 (aligned 2048)
[ 92.720000] UBI: data offset: 4096
[ 92.780000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 64 bytes from PEB 255:0, read 64 bytes
[ 92.800000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 512 bytes from PEB 255:2048, read 512 bytes
[ 92.860000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 64 bytes from PEB 534:0, read 64 bytes
[ 92.890000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 512 bytes from PEB 534:2048, read 512 bytes
[ 93.180000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 64 bytes from PEB 1553:0, read 64 bytes
[ 93.200000] UBI error: ubi_io_read: error -74 (ECC error) while
reading 512 bytes from PEB 1553:2048, read 512 bytes
[ 93.320000] UBI: max. sequence number: 3382
[ 93.370000] UBI: attached mtd6 to ubi0
[ 93.380000] UBI: MTD device name: "rootfs"
[ 93.390000] UBI: MTD device size: 246 MiB
[ 93.400000] UBI: number of good PEBs: 1973
[ 93.410000] UBI: number of bad PEBs: 0
[ 93.420000] UBI: number of corrupted PEBs: 0
[ 93.430000] UBI: max. allowed volumes: 128
[ 93.440000] UBI: wear-leveling threshold: 4096
And so on (see full log in attachment)
Same partition working well with .34 kernel
console=tty0 loglevel=8 regular_boot glamo_mci.sd_max_clk=15000000
mem=127M panic=20 root=/dev/mmcblk0p2 rootwait
mtdparts=physmap-flash:-(nor);neo1973-nand:0x00040000(u-boot),0x00040000(u-boot_env),0x00800000(kernel),0x000a0000(splash),0x00040000(factory),0x0f6a0000(rootfs) ro
.config is in attachment. i tried radek's config too - same story.
This is quite grave, as i can't boot or mount nand.
Gennady Kupava
2011-01-16 19:38:13 UTC
Permalink
Post by Lars-Peter Clausen
* One WSOD fix in the jbt67k4 driver.
As i already stated in IRC, this one has same effect as very dirty patch
already used by all distros, implemented by me with idea by ThibG, since
September 2010. KMS tree had similar patch even before that date.

Speaking about WSes we have one more patch, which proved to fix some
WSes on blank/unblank (including rotations and mode changes):
https://github.com/radekp/linux-2.6/commit/5a6bd71ba228b8613137241898038a3c0354327c
This patch is working not only for 2-4-2 as Radek named it, but also
fixes WSes perfectly with old 4-4-4 timings.

I am sorry to ask once again: may be you can merge some of patches used
in distros and proven to be working and essential into your branch to
not invent things again and again? May be you can tell at least what is
exact problem of each patch, and probably author can fix that problems?

Gennady
Loading...