[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] CPUIDLE: enable MSI capable HPET for timer broadcast
The HPET broadcast was default not enabled because the old code use HPET channel 0 in legacy replacing mode which will hide both PIT & RTC irqs and cause issues if RTC is needed in some cases. The upstream default broadcast timer is PIT, which is in periodic mode (100HZ) and would be expensive to be used as oneshot. MSI capable HPET is coming into being. It is capable to deliver interrupt through FSB directly, and has no side effect. This patch extends support for MSI HPET based on original legacy HPET code. The broadcast timer selection logic becomes: 1. if MSI capable HPET available, use multiple HPET channels (no more than possible cpu num) in MSI mode; 2. else if legacy replacing mode available for HPET & 'hpetbroadcast' option is given in cmd line, use HPET channel 0 in legacy mode; 3 else use PIT. While entering broadcast, it gets a hpet channel (look for a spare one first, if failing allocate a shared one), attach to current cpu, setup the irq affinity & broadcast cpumask. While exiting broadcast, it detach the used hpet channel and try to change the owner if the broadcast mask is not empty. Some optimizations(static affinity) were done for (MSI HPET channels >= possible cpu num) case. A new hw_interrupt_controller 'HPET_MSI' is created for HPET MSI interrupt handling. Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx> Attachment:
hpet-msi-20090320.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |