kernel-fxtec-pro1x/arch/powerpc/sysdev/Kconfig

# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.txt.
#

config PPC4xx_PCI_EXPRESS
	bool
	depends on PCI && 4xx
	default n

config PPC_MSI_BITMAP
	bool
	depends on PCI_MSI
	default y if MPIC
	default y if FSL_PCI

source "arch/powerpc/sysdev/xics/Kconfig"

config PPC_SCOM
	bool

config SCOM_DEBUGFS
	bool "Expose SCOM controllers via debugfs"
	depends on PPC_SCOM
	default n
[POWERPC] 4xx: PLB to PCI Express support This adds to the previous 2 patches the support for the 4xx PCI Express cells as found in the 440SPe revA, revB and 405EX. Unfortunately, due to significant differences between these, and other interesting "features" of those pieces of HW, the code isn't as simple as it is for PCI and PCI-X and some of the functions differ significantly between the 3 implementations. Thus, not only this code can only support those 3 implementations for now and will refuse to operate on any other, but there are added ifdef's to avoid the bloat of building a fairly large amount of code on platforms that don't need it. Also, this code currently only supports fully initializing root complex nodes, not endpoint. Some more code will have to be lifted from the arch/ppc implementation to add the endpoint support, though it's mostly differences in memory mapping, and the question on how to represent endpoint mode PCI in the device-tree is thus open. Many thanks to Stefan Roese for testing & fixing up the 405EX bits ! Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Stefan Roese <sr@denx.de> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> 2007-12-20 21:39:24 -07:00			`# For a description of the syntax of this configuration file,`
			`# see Documentation/kbuild/kconfig-language.txt.`
			`#`

			`config PPC4xx_PCI_EXPRESS`
			`bool`
			`depends on PCI && 4xx`
			`default n`
powerpc: Split-out common MSI bitmap logic into msi_bitmap.c There are now two almost identical implementations of an MSI bitmap allocator, one in mpic_msi.c and the other in fsl_msi.c. Merge them together and put the result in msi_bitmap.c. Some of the MPIC bits will remain to provide a nicer interface for the MPIC users. In the process we fix two buglets. The first is that the allocation routines, now msi_bitmap_alloc_hwirqs(), returned an unsigned result, even though they use -1 to indicate allocation failure. Although all the callers were checking correctly, it is much better for the routine to just return an int. At least until someone wants > ~2 billion MSIs. The second buglet is that the device tree reservation logic only allowed power-of-two reservations. AFAICT that didn't effect any existing code but it's nicer if we can reserve arbitrary irqs from MSI use. We also add some selftests, which exposed the two buglets and now test for them, as well as some basic sanity tests. The tests are only built when CONFIG_DEBUG_KERNEL=y. Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Paul Mackerras <paulus@samba.org> 2008-08-05 17:10:01 -06:00
			`config PPC_MSI_BITMAP`
			`bool`
			`depends on PCI_MSI`
			`default y if MPIC`
			`default y if FSL_PCI`
powerpc/xics: Rewrite XICS driver This is a significant rework of the XICS driver, too significant to conveniently break it up into a series of smaller patches to be honest. The driver is moved to a more generic location to allow new platforms to use it, and is broken up into separate ICP and ICS "backends". For now we have the native and "hypervisor" ICP backends and one common RTAS ICS backend. The driver supports one ICP backend instanciation, and many ICS ones, in order to accomodate future platforms with multiple possibly different interrupt "sources" mechanisms. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2011-04-03 21:46:58 -06:00
			`source "arch/powerpc/sysdev/xics/Kconfig"`

powerpc: Add SCOM infrastructure SCOM is a side-band configuration bus implemented on some processors. This code provides a way for code to map and operate on devices via SCOM, while the details of how that is implemented is left up to a SCOM "controller" in the platform code. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2011-04-14 16:31:58 -06:00			`config PPC_SCOM`
			`bool`

			`config SCOM_DEBUGFS`
			`bool "Expose SCOM controllers via debugfs"`
			`depends on PPC_SCOM`
			`default n`