[Debian-eeepc-devel] Some experiences with kernel 2.6.31

[Luca Niccoli]

2009/10/10 Alan Jenkins <sourcejedi.lkml at googlemail.com>:

> The rfkill initialisation is actually redundant.  It will go away when
> the "rfkill input handler" is removed, which is scheduled for 2.6.33.
> If you like, you can preview the removal by building a kernel with
> CONFIG_EMBEDDED=y and CONFIG_RFKILL_INPUT=n.

I thought eeepc-acpi-scripts depended on it, but I'm building a kernel
without it to check.

> I guess we should also optimize the camera delay for 2.6.33 (normally
> it will be enabled already so we don't need to suffer the delay).

I'm wondering, can't we initialize everything in parallel?
The init time seems to grow more or less linearly enabling wifi and
bluetooth (see below), maybe they could be initialized together with
the camera.

> I can reproduce both my delays at run-time, e.g. (as root)
>
> cd /sys/devices/platform/eeepc/
> echo 0 > camera
> time echo 1 > camera

It takes 500ms both for switching the camera off and for switching it on again.

> and
>
> for d in /sys/devices/platform/eeepc/rfkill/rfkill*; do


For the wlan (rt2860, plus eeepl_laptop patch from darren):
1200ms for switching it on, 300ms to switch it off
For the bluetooth:
1100ms on, 200ms off


> - so you could use this to see whether your delays are purely from
> these known causes, or if there is something else going on.  I would
> be interested to hear any results.


I tried booting with:
bluetooth and wifi off (the camera is always switched on at boot time
in 2.6.31), eeepc_laptos initcall returns after 2900ms,
bluetooth and wifi on: 4670ms
only wifi on: 3830ms
only bluetooth on: 3810ms

Cheers,

Luca