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

[Alan Jenkins]

On 10/10/09, Luca Niccoli <lultimouomo at gmail.com> wrote:
> 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.

eeepc-acpi-scripts does have code to toggle the wifi when the hotkey
is pressed (I checked the tarball for 1.1.0).  In theory I think this
conflicts with rfkill-input and should be more careful.  In practise
it seems to work either way, though I'm not going to speculate as to
why :-).

>> 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 think we can avoid the *known* delays altogether.  We should only
need to suffer the camera delay if it was disabled in the BIOS and we
have to enable it - but that should be a one-off, because the BIOS
remembers the setting for us.

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

Cool.  So that leave 2900 - 0500 = ~2400ms of unknown delays.

The easy option is to force the entire driver to load asynchronously
(i.e. in the background), like the acpi battery driver.

The hard way is to work out why Asus have added these delays and what
they do about them on the pre-installed OS's.  The obvious place to
look would be the acpi INIT method.  I am curious as to what your
"acpidump" output looks like.  But to be honest, I doubt it's worth
the effort.  Especially if the answer is that they don't install Linux
anymore and the Windows driver is loaded as a background process :-).

Thanks
Alan