Matthew Wilcox wrote:
On Fri, Oct 17, 2008 at 11:36:47AM +0900, Kenji Kaneshige wrote:
Phil Endecott wrote:
Dear Experts,
Some of you may have heard about Arjan van de Ven and Auke Kok's work
to get an ASUS EEE 901 to boot in 5 seconds. I'm trying to achieve
something similar on my own '901.
One of the things that Arjan and Auke didn't do in their startup was
wireless networking. This can be switched on and off using a special
key combination, and uses pcie hotplug. I'm not entirely certain how
it all hangs together, but what seems to work is loading pciehp either
as a module or built in to the kernel, and setting pciehp_force=1.
This is functional, but very slow because of at least one msleep(1000)
in pciehp_ctrl.c. Arjan & Auke boot their kernel in less than a second,
but mine spends does about four of these 1-second waits :-(
So, what can I do about this? I am a bit suspicious of the pciehp_force
parameter; what is it supposed to do? I only need hotplugging on this
one device; can I avoid these delays for initialisation associated with
other PCI devices that cannot be hot-unplugged? Can the 1 second delay
safely be reduced? Can it be made to occur concurrently with other
activity?
If your platform allows hotplug using OS native hotplug driver (pciehp
in Linux) to handle hotplug slots, you don't need pciehp_force. The
pciehp_force parameter is supposed to be used only for testing purpose
if you want pciehp to handle hotplug slots even though your platform
doesn't allow hotplug using OS native hotplug driver.
While true, this doesn't really help him.
Is there any way of getting rid of this one-second delay?
The one second delay at pciehp probe time happens only when pciehp_force
is set. So one of the solution is removing pciehp_force parameter. But if
Phil's platform needs pciehp_force for pciehp to run, it doesn' solve the
problem. But please note that pciehp_force is for testing purpose.
When pciehp_force option is specified, pciehp tries to enable slot at the
driver loading time, and one-second delay is in this enabling operation.
This pciehp_force behavior was introduced by the commit
0a3c33d77ff7ad5b988997536a8f09c49e35ad20 (by Mark Load). We can change
around this to get rid of the on-second delay. But, unfortunately, I don't
know why this behavior was required very much, so I don't have any idea
about this.
On the other hand, I have one idea to reduce the wait time, regardless of
pciehp_force option. I think Polling Data Link Layer Link Active bit
instead of one-second delay would reduce the wait time. In additon, we can
use event driven method instead of polling if the platform supports Data
Link Layer State Changed event. I'll try it.
Thanks,
Kenji Kaneshige
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
