On 10/10/09, Luca Niccoli <[email protected]> wrote: > 2009/10/10 Alan Jenkins <[email protected]>: > >> 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 _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
