2.6.37

[Lars-Peter Clausen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0kxcwACgkQBX4mSR26RiOR9ACeJ+twIG4brWJS22ogoSeV3N9k
OYUAoIEv+/h497hAW/ZD/b+HXbNFQYSY
=5j/S
-----END PGP SIGNATURE-----

[Radek Polak]

Lars-Peter Clausen wrote:

> 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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2011 10:29 AM, Radek Polak wrote:

> Lars-Peter Clausen wrote:
>
>> 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
>

Hi

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

- - Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0ls1kACgkQBX4mSR26RiOhPwCfQaZKGiGjTMBvbmn0P6Cg39Bj
t7gAn37mSrZ54OGU+GgLABfs4D1FZwXe
=R3Ws
-----END PGP SIGNATURE-----

[Lars-Peter Clausen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/06/2011 01:19 PM, Lars-Peter Clausen wrote:

> On 01/06/2011 10:29 AM, Radek Polak wrote:
>> Lars-Peter Clausen wrote:
>
>>> 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
>
>
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0ltzsACgkQBX4mSR26RiMxMgCeJSYGLjEWg8eK5jEHgjfSSK4K
ma8An24j0PaO8RCu5/C+nFeNdyFeg6En
=NYci
-----END PGP SIGNATURE-----

[Radek Polak]

Lars-Peter Clausen wrote:

> 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]

>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]

On Sat, 8 Jan 2011 10:50:07 +0100
Petr Vanek <[hidden email]> (PV) wrote:

>>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]

Petr Vanek wrote:

> 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...?

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]

Hi Lars and Radek,

Radek Polak <[hidden email]> writes:
> 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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi

On 01/08/2011 03:44 PM, Timo Juhani Lindfors wrote:
> > Hi Lars and Radek,
> >
> > Radek Polak <[hidden email]> writes:
>> >> 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 :)

> > $ 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?
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

> >
> > 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.
> >
> > 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?

Same here:
/sys/bus/platform/devices/pcf50633-mbc/usb_curlim

> >
> > 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.
> >
> >

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0osTIACgkQBX4mSR26RiPBnACeIQ6jjXl4LDUn6wSdkvOcAV60
K8YAnR8jMN9jRy41Qwy6Q5a0dE2p1Wnb
=Dq2V
-----END PGP SIGNATURE-----

[Timo Juhani Lindfors]

Lars-Peter Clausen <[hidden email]> writes:
> A good path to use for changing the resolution is
>
> /sys/class/lcd/jbt6k74-lcd/device/resolution

Thanks.

> 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


>> > /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

$ 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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2011 08:55 PM, Timo Juhani Lindfors wrote:

> Lars-Peter Clausen <[hidden email]> writes:
>> A good path to use for changing the resolution is
>>
>> /sys/class/lcd/jbt6k74-lcd/device/resolution
>
> Thanks.
>
>> 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

>
>
>>>> /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
>
> $ 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0owtEACgkQBX4mSR26RiPPaACdHKpZJ/W8zHyxiLHxFfs/3urq
4cUAnip69Q6uwOiuAcELOOqOblc21F1Z
=aagj
-----END PGP SIGNATURE-----

[Timo Juhani Lindfors]

Hi,

Lars-Peter Clausen <[hidden email]> writes:
> 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.

[Timo Juhani Lindfors]

Lars-Peter Clausen <[hidden email]> writes:
> 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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2011 09:16 PM, Timo Juhani Lindfors wrote:

> > Lars-Peter Clausen <[hidden email]> writes:
>> >> 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".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0ox+wACgkQBX4mSR26RiOIwwCZAZEkD6o0I3fwhwLdLFn9x6aR
Dm4AniGlfuxkjUmD/l4XcWIYCE2LC2ll
=HVO7
-----END PGP SIGNATURE-----

[Timo Juhani Lindfors]

Lars-Peter Clausen <[hidden email]> writes:
> On 01/08/2011 09:16 PM, Timo Juhani Lindfors wrote:
>> > 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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2011 09:38 PM, Timo Juhani Lindfors wrote:

> Lars-Peter Clausen <[hidden email]> writes:
>> On 01/08/2011 09:16 PM, Timo Juhani Lindfors wrote:
>>>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0p6/kACgkQBX4mSR26RiPuIACfTY8hUAaRES+NN8qQ8esYpOQ6
JXQAnixlKG7T9V08WgiRv2i3gKUTS5Um
=NFcA
-----END PGP SIGNATURE-----

[Radek Polak]

Timo Juhani Lindfors wrote:

> 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]

Hi,

Il 09/01/2011 19:46, Radek Polak ha scritto:

> Timo Juhani Lindfors wrote:
>
>> 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]

Am 10.01.2011 10:15, schrieb Riccardo Magliocchetti:

> Hi,
>
> Il 09/01/2011 19:46, Radek Polak ha scritto:
>> Timo Juhani Lindfors wrote:
>>
>>> 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