- 20 Dec, 2007 40 commits
-
-
Lucas Woods authored
Signed-off-by:
Lucas Woods <woodzy@gmail.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Lucas Woods authored
Signed-off-by:
-
Li Zefan authored
The casting is safe only when the list_head member is the first member of the structure, and even then it is better to use the address of the list_head structure member. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
-
Cyrill Gorcunov authored
This fixes a possible NULL pointer dereference inside of strncmp() if of_get_property() fails. Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
-
Stephen Rothwell authored
We were using -mno-minimal-toc on everything in arch/powerpc/kernel, which means that all the functions in there were putting all their TOC entries in the top-level TOC, and it was overflowing on an allyesconfig build. For various reasons, prom_init.c does need -mno-minimal-toc, but the other .c files in there can use sub-TOCs quite happily. This change is sufficient for now to stop the TOC overflowing; other directories under arch/powerpc also use -mno-minimal-toc and could also be changed later if necessary. Lmbench runs with and without this patch showed no significant speed differences. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
The PCI IRQ code has a fallback when the device-tree parsing fails, that tries to map the interrupt indicated by PCI_INTERRUPT_LINE if the firmware set something in there. This is a bit fragile but has proven useful in some cases so far. However, it's causing us to incorrectly try to map interrupt 0 on various setups, so let's prevent that case, as none of the cases where the fallback is legit should have an IRQ 0. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch changes the PowerPC PCI code to disable IO and/or Memory decoding on a PCI device when a resource of that type failed to be allocated. This is done to avoid having unallocated dangling BARs enabled that might try to decode on top of other devices. If a proper resource is assigned later on, then pci_enable_device() will take care of re-enabling decoding. Signed-off-by:
-
Benjamin Herrenschmidt authored
Apple firmware has a strange way to "close" bridge resources by setting them to some bogus values that overlap RAM (strangely, I haven't seen it conflicting with DMA so far...). This explicitely closes them to avoid problems. Previously, they would be closed as a consequence of failing to be allocated, but this makes it more explicit, and thus the log message is more explicit too. Signed-off-by:
-
Benjamin Herrenschmidt authored
The device node for the HT bridge on G5s doesn't contain useful ranges. We used to give it a bunch of the known PCI space and then punch a "hole" in it based on where the AGP or PCIe region was. This reworks it to use the actual register in the bridge that controls the decoding instead. Signed-off-by:
-
Benjamin Herrenschmidt authored
This enables the PCI code to see the device that represents the HT host bridge on the PowerMac G5. Signed-off-by:
-
Benjamin Herrenschmidt authored
Our implementation of pcibios_enable_device() has a couple of problems. One is that it should not check IORESOURCE_UNSET, as this might be left dangling after resource assignment (shouldn't but there are bugs), but instead, we make it check resource->parent which should be a reliable indication that the resource has been successfully claimed (it's in the resource tree). Then, we also need to skip ROM resources that haven't been enabled as x86 does. Signed-off-by:
-
Benjamin Herrenschmidt authored
It should now be safe to re-assign unassigned resources on 64 bits PowerMac machines (G5s). This clears pci_probe_only on those. Signed-off-by:
-
Benjamin Herrenschmidt authored
Powermac's use of the pcibios_enable_device_hook() got slightly broken by the recent PCI merge in that it won't be called for the "initial" case of assigning resources to a previously unassigned device. This was an abuse of that hook anyway, so instead we now use a header quirk. While at it, we move a #ifdef CONFIG_PPC32 to enclose more code that is only ever used on 32 bits. Signed-off-by:
-
Benjamin Herrenschmidt authored
This merge the two implementations, based on the previously fixed up 32 bits one. The pcibios_enable_device_hook in ppc_md is now available for ppc64 use. Also remove the new unused "initial" parameter from it and fixup users. Signed-off-by:
-
Benjamin Herrenschmidt authored
Our implementation of pcibios_enable_device() incorrectly ignores the mask argument and always checks that all resources have been allocated, which isn't the right thing to do anymore. Signed-off-by:
-
Benjamin Herrenschmidt authored
The way iSeries manages PCI IO and Memory resources is a bit strange and is based on overriding the content of those resources with home cooked ones afterward. This changes it a bit to better integrate with the new resource handling so that the "virtual" tokens that iSeries replaces resources with are done from the proper per-device fixup hook, and bridge resources are set to enclose that token space. This fixes various things such as the output of /proc/iomem & ioports, among others. This also fixes up various boot messages as well. Signed-off-by:
-
Benjamin Herrenschmidt authored
The 32 bits PCI code now uses the generic code for assigning unassigned resources and an algorithm similar to x86 for claiming existing ones. This works far better than the 64 bits code which basically can only claim existing ones (pci_probe_only=1) or would fall apart completely. This merges them so that the new 32 bits implementation is used for both. 64 bits now gets the new PCI flags for controlling the behaviour, though the old pci_probe_only global is still there for now to be cleared if you want to. I kept a pcibios_claim_one_bus() function mostly based on the old 64 bits code for use by the DLPAR hotplug. This will have to be cleaned up, thought I hope it will work in the meantime. Signed-off-by:
-
Benjamin Herrenschmidt authored
The PCI code in 32 and 64 bits fixes up resources differently. 32 bits uses a header quirk plus handles bridges in pcibios_fixup_bus() while 64 bits does things in various places depending on whether you are using OF probing, using PCI hotplug, etc... This merges those by basically using the 32 bits approach for both, with various tweaks to make 64 bits work with the new approach. Signed-off-by:
-
Benjamin Herrenschmidt authored
This merges the PowerPC 32 and 64 bits version of pcibios_resource_to_bus and pcibios_bus_to_resource(). Signed-off-by:
-
Benjamin Herrenschmidt authored
This adds flags the platforms can use to enable domain numbers in /proc/bus/pci. Signed-off-by:
-
Benjamin Herrenschmidt authored
The 32 bits PCI code carries an old hack that was only useful for G5 machines. Nowdays, the 32 bits kernel doesn't support any of those machines anymore so the hack is basically never used, so remove it. Signed-off-by:
-
Benjamin Herrenschmidt authored
This adds to the 32 bits PCI code some flags, replacing the old pci_assign_all_busses global, that allow us to control various aspects of the PCI probing, such as whether to re-assign all resources or not, or to not try to assign anything at all. This also adds the flag x86 already has to avoid ISA alignment on bridges that don't have ISA forwarding enabled (no legacy devices on the top level bus) and sets it for PowerMacs. Signed-off-by:
-
Benjamin Herrenschmidt authored
The 32 bits PowerPC PCI code has a hack for use by some PowerMacs to try to re-open PCI<->PCI bridge IO resources that were closed by the firmware. This is no longer necessary as the generic code will now do that for us. Signed-off-by:
-
Benjamin Herrenschmidt authored
This makes the 32 bits PowerPC PCI code use the generic code to assign resources to devices that had unassigned or conflicting resources. This allow us to remove the local implementation that was incomplete and could not assign for example a PCI<->PCI bridge from scratch, which is needed on various embedded platforms. Signed-off-by:
-
Benjamin Herrenschmidt authored
There's a stale & bogus piece of code in 32 bits PCI code that complains about ISA related alignment issues. Just remove it. Signed-off-by:
-
David Gibson authored
This patch alters the kernel makefiles to build dtc from the sources embedded in the previous patch. It also changes the arch/powerpc/boot/wrapper script to use the embedded dtc, rather than expecting a copy of dtc already installed on the system. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
David Gibson authored
This incorporates a copy of dtc into the kernel source, in arch/powerpc/boot/dtc-src. This commit only imports the upstream sources verbatim, a later commit will actually link it into the kernel Makefiles and use the embedded code during the kernel build. Signed-off-by:
-
Olof Johansson authored
There's nothing in holly.c that needs linux/ide.h, just remove it from the list of includes. Signed-off-by:
Olof Johansson <olof@lixom.net> Acked-by:
Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by:
-
joe@perches.com authored
Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
joe@perches.com authored
Signed-off-by:
-
joe@perches.com authored
Signed-off-by:
-
joe@perches.com authored
Signed-off-by:
-
Michael Ellerman authored
PowerPC currently doesn't implement pci_set_dma_mask(), which means drivers calling it will get the generic version in drivers/pci/pci.c. The powerpc dma mapping ops include a dma_set_mask() hook, which luckily is not implemented by anyone - so there is no bug in the fact that the hook is currently never called. However in future we'll add implementation(s) of dma_set_mask(), and so we need pci_set_dma_mask() to call the hook. To save adding a hook to the dma mapping ops, pci-set_consistent_dma_mask() simply calls the dma_set_mask() hook and then copies the new mask into dev.coherenet_dma_mask. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
Milton Miller authored
We have multiple calls to has_feature being inlined, but gcc can't be sure that the store via get_paca() doesn't alias the path to cur_cpu_spec->feature. Reorder to put the calls to read_purr and read_spurr adjacent to each other. To add a sense of consistency, reorder the remaining lines to perform parallel steps on purr and scaled purr of each line instead of calculating and then using one value before going on to the next. In addition, we can tell gcc that no SPURR means no PURR. The test is completely hidden in the PURR case, and in the !PURR case the second test is eliminated resulting in the simple register copy in the out-of-line branch. Further, gcc sees get_paca()->system_time referenced several times and allocates a register to address it (shadowing r13) instead of caching its value. Reading into a local varable saves the shadow of r13 and removes a potentially duplicate load (between the nested if and its parent). Signed-off-by:
Milton Miller <miltonm@bga.com> Signed-off-by:
-
Milton Miller authored
If CPU_FTR_PURR is not set, we will never set cpu_purr_data->initialized. Checking via __get_cpu_var on 64 bit avoids one dependent load compared to cpu_has_feature in the not-present case, and is always required when it is present. The code is under CONFIG_VIRT_CPU_ACCOUNTING so 32 bit will not be affected. Signed-off-by:
-
Milton Miller authored
timer_interrupt() was calculating per_cpu_offset several times, having to start from the toc because of potential aliasing issues. Placing both decrementer per_cpu varables in a struct and calculating the address once with __get_cpu_var results in better code on both 32 and 64 bit. Signed-off-by:
-
Milton Miller authored
Use __get_cpu_var(x) instead of per_cpu(x, smp_processor_id()), as it is optimized on ppc64 to access the current cpu's per-cpu offset directly; it's local_paca.offset instead of TOC->paca[local_paca->processor_id].offset. This is the trivial portion, two functions with one use each. Signed-off-by:
-
Milton Miller authored
as its only called from time_init, which is __init. Also remove unneeded forward declaration. Signed-off-by:
-
Milton Miller authored
The per-processor interrupt request register and current processor priority register are only accessed on the current cpu. In fact the hypervisor doesn't even let us choose which cpu's registers to access. The only function to use cpu twice is xics_migrate_irqs_away, not a fast path. But we can cache the result of get_hard_processor_id() instead of calling get_hard_smp_processor_id(cpu) in a loop across the call to rtas. Years ago the irq code passed smp_processor_id into get_irq, I thought we might initialize the CPPR third party at boot as an extra measure of saftey, and it made the code symmetric with the qirr (queued interrupt for software generated interrupts), but now it is just extra and sometimes unneeded work to pass it down. Signed-off-by:
-
Ishizaki Kou authored
This splits the machine definition for celleb into two definitions, one for celleb_beat, and the other for celleb_native. Though this looks complex because of sorting some functions, there are no more semantic changes than that for the splitting. Signed-off-by:
Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
