lisa/android_kernel_xiaomi_sm8350
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
25f30389dd
android_kernel_xiaomi_sm8350/drivers/pci/Kconfig

63 lines
2.1 KiB
Plaintext
Raw Normal View History

Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 18:20:36 -04:00
#
# PCI configuration
#
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
[SPARC64]: Add PCI MSI support on Niagara. This is kind of hokey, we could use the hardware provided facilities much better. MSIs are assosciated with MSI Queues. MSI Queues generate interrupts when any MSI assosciated with it is signalled. This suggests a two-tiered IRQ dispatch scheme: MSI Queue interrupt --> queue interrupt handler MSI dispatch --> driver interrupt handler But we just get one-level under Linux currently. What I'd like to do is possibly stick the IRQ actions into a per-MSI-Queue data structure, and dispatch them form there, but the generic IRQ layer doesn't provide a way to do that right now. So, the current kludge is to "ACK" the interrupt by processing the MSI Queue data structures and ACK'ing them, then we run the actual handler like normal. We are wasting a lot of useful information, for example the MSI data and address are provided with ever MSI, as well as a system tick if available. If we could pass this into the IRQ handler it could help with certain things, in particular for PCI-Express error messages. The MSI entries on sparc64 also tell you exactly which bus/device/fn sent the MSI, which would be great for error handling when no registered IRQ handler can service the interrupt. We override the disable/enable IRQ chip methods in sun4v_msi, so we have to call {mask,unmask}_msi_irq() directly from there. This is another ugly wart. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-10 20:41:02 -05:00
depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || SPARC64
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 18:20:36 -04:00
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
generate an interrupt using an inbound Memory Write on its
PCI bus instead of asserting a device IRQ pin.
[PATCH] PCI: Provide a boot parameter to disable MSI Several drivers are starting to grow options to disable MSI. However, it's often a host chipset issue, not something which individual drivers should handle. So we add the pci=nomsi kernel parameter to allow the user to disable MSI modes for systems we haven't added to the quirk list yet. Signed-off-by: Matthew Wilcox <matthew@wil.cx> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-06 00:33:34 -05:00
Use of PCI MSI interrupts can be disabled at kernel boot time
by using the 'pci=nomsi' option. This disables MSI for the
entire system.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 18:20:36 -04:00
If you don't know what to do here, say N.
PCI: enable driver multi-threaded probe This provides a build and run-time option to turn on multhreaded probe for all PCI drivers. It can cause bad problems on multi-processor machines that take a while to find their root disks, and play havoc on machines that don't use persistant device names for block or network devices. But it can cause speedups on some machines, my tiny laptop's boot goes up by 0.4 seconds, and my desktop boots up several seconds faster. Use at your own risk!!! Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-18 13:59:59 -04:00
config PCI_MULTITHREAD_PROBE
bool "PCI Multi-threaded probe (EXPERIMENTAL)"
[PATCH] PCI: disable PCI_MULTITHREAD_PROBE Unfortunatly, no one reads Kconfig help entries :( Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-14 19:40:00 -05:00
depends on PCI && EXPERIMENTAL && BROKEN
PCI: enable driver multi-threaded probe This provides a build and run-time option to turn on multhreaded probe for all PCI drivers. It can cause bad problems on multi-processor machines that take a while to find their root disks, and play havoc on machines that don't use persistant device names for block or network devices. But it can cause speedups on some machines, my tiny laptop's boot goes up by 0.4 seconds, and my desktop boots up several seconds faster. Use at your own risk!!! Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-18 13:59:59 -04:00
help
Say Y here if you want the PCI core to spawn a new thread for
every PCI device that is probed. This can cause a huge
speedup in boot times on multiprocessor machines, and even a
smaller speedup on single processor machines.
But it can also cause lots of bad things to happen. A number
Fix misc Kconfig typos Fix various Kconfig typos. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-11-29 23:22:59 -05:00
of PCI drivers cannot properly handle running in this way,
PCI: enable driver multi-threaded probe This provides a build and run-time option to turn on multhreaded probe for all PCI drivers. It can cause bad problems on multi-processor machines that take a while to find their root disks, and play havoc on machines that don't use persistant device names for block or network devices. But it can cause speedups on some machines, my tiny laptop's boot goes up by 0.4 seconds, and my desktop boots up several seconds faster. Use at your own risk!!! Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-18 13:59:59 -04:00
some will just not work properly at all, while others might
decide to blow up power supplies with a huge load all at once,
so use this option at your own risk.
It is very unwise to use this option if you are not using a
boot process that can handle devices being created in any
Fix typos in doc and comments Changes persistant -> persistent. www.dictionary.com does not know persistant (with an A), but should it be one of those things you can spell in more than one correct way, let me know. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-11-29 23:32:19 -05:00
order. A program that can create persistent block and network
PCI: enable driver multi-threaded probe This provides a build and run-time option to turn on multhreaded probe for all PCI drivers. It can cause bad problems on multi-processor machines that take a while to find their root disks, and play havoc on machines that don't use persistant device names for block or network devices. But it can cause speedups on some machines, my tiny laptop's boot goes up by 0.4 seconds, and my desktop boots up several seconds faster. Use at your own risk!!! Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-07-18 13:59:59 -04:00
device names (like udev) is a good idea if you wish to use
this option.
Again, use this option at your own risk, you have been warned!
When in doubt, say N.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 18:20:36 -04:00
config PCI_DEBUG
bool "PCI Debugging"
depends on PCI && DEBUG_KERNEL
help
Say Y here if you want the PCI core to produce a bunch of debug
messages to the system log. Select this if you are having a
problem with PCI support and want to see more of what is going on.
When in doubt, say N.
[PATCH] Initial generic hypertransport interrupt support This patch implements two functions ht_create_irq and ht_destroy_irq for use by drivers. Several other functions are implemented as helpers for arch specific irq_chip handlers. The driver for the card I tested this on isn't yet ready to be merged. However this code is and hypertransport irqs are in use in a few other places in the kernel. Not that any of this will get merged before 2.6.19 Because the ipath-ht400 is slightly out of spec this code will need to be generalized to work there. I think all of the powerpc uses are for a plain interrupt controller in a chipset so support for native hypertransport devices is a little less interesting. However I think this is a half way decent model on how to separate arch specific and generic helper code, and I think this is a functional model of how to get the architecture dependencies out of the msi code. [akpm@osdl.org: Kconfig fix] Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Greg KH <greg@kroah.com> Cc: Andi Kleen <ak@muc.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 05:16:55 -04:00
config HT_IRQ
bool "Interrupts on hypertransport devices"
default y
[PATCH] HT_IRQ must depend on PCI CONFIG_PCI=n, CONFIG_HT_IRQ=y results in the following compile error: ... LD vmlinux arch/i386/mach-generic/built-in.o: In function `apicid_to_node': summit.c:(.text+0x53): undefined reference to `apicid_2_node' arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq': (.text+0xcf79): undefined reference to `write_ht_irq_low' arch/i386/kernel/built-in.o: In function `arch_setup_ht_irq': (.text+0xcf85): undefined reference to `write_ht_irq_high' arch/i386/kernel/built-in.o: In function `k7nops': alternative.c:(.data+0x1358): undefined reference to `mask_ht_irq' alternative.c:(.data+0x1360): undefined reference to `unmask_ht_irq' make[1]: *** [vmlinux] Error 1 Bug report by Jesper Juhl. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-11 04:22:04 -04:00
depends on PCI && X86_LOCAL_APIC && X86_IO_APIC
[PATCH] Initial generic hypertransport interrupt support This patch implements two functions ht_create_irq and ht_destroy_irq for use by drivers. Several other functions are implemented as helpers for arch specific irq_chip handlers. The driver for the card I tested this on isn't yet ready to be merged. However this code is and hypertransport irqs are in use in a few other places in the kernel. Not that any of this will get merged before 2.6.19 Because the ipath-ht400 is slightly out of spec this code will need to be generalized to work there. I think all of the powerpc uses are for a plain interrupt controller in a chipset so support for native hypertransport devices is a little less interesting. However I think this is a half way decent model on how to separate arch specific and generic helper code, and I think this is a functional model of how to get the architecture dependencies out of the msi code. [akpm@osdl.org: Kconfig fix] Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Greg KH <greg@kroah.com> Cc: Andi Kleen <ak@muc.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-10-04 05:16:55 -04:00
help
This allows native hypertransport devices to use interrupts.
If unsure say Y.
Reference in New Issue Copy Permalink